This standardizes this functionality within the Search module so
it doesn't need to be imported by other search backends from Meilisearch
Also integrate its filtering rules into Search.indexable?/1 for consistency
The Logger does not get reconfigured when running in the test env,
the added and on_exit removed settings below should have no effect
besides triggering the deprecation warnings. To make breakage even less
possible, async is turned off for these tests.
TransferTask test does almost the same with the Application env.
Trying to do a two-release migration proved to be very hacky and ugly.
Instead this is preparation for moving defaults first and then merging
the old configuration left in admin's config file at runtime while still
emitting a warning. This hopefully will be a lot nicer and less
complicated.
Descriptions of MRF policies are gathered at compile-time and use
Pleroma.Docs.Generator.list_behaviour_implementations func, which
depends on modules implementing the queried behaviour to be loaded.
Otherwise descriptions for MRFs can be missing from the AdminAPI route.
Note: @behaviour cannot be injected in the __using__ macro. It causes a
loop in the compiler which leads to memory exhaustion. Hence why
@behaviour is still defined separately in the MRFs.
Elixir 1.19 started emitting warnings about our use of:
config :logger, :console and
config :logger, backends: []
which got split in 1.15 to :default_handler, :default_formatter, and
LoggerBackends.add(backend) respectively.
On Pleroma startup it is now necessary to add the additional logger
backends at runtime (done with configure_logger() in application.ex).
New config key :pleroma, :logger_backends: [] has replaced the older
backends array. The logger_backends package is now used to facilitate
usage of other logger backends besides the default one (:logger_std_h
from OTP).
Warnings were added to Pleroma startup to warn about the usage of
:logger, backends and additional logic was introduced to make addition
of ExSyslogger to admin's configuration less dumb.
Ref: https://hexdocs.pm/logger/1.15.0/Logger.html#module-backends-and-backwards-compatibility
It is no longer possible to match regexes. Instead at least match that
the sources of the regexes (regexes themselves) are the same.
Notice the +1 Reference number below.
2) test subdomain_match/2 wildcard domains with one subdomain (Pleroma.Web.ActivityPub.MRFTest)
test/pleroma/web/activity_pub/mrf_test.exs:36
Assertion with == failed
code: assert regexes == [~r/^(.*\.)*unsafe.tld$/i]
left: [%Regex{opts: [:caseless], re_pattern: {:re_pattern, 1, 0, 0, #Reference<0.378940835.3277193222.129648>}, source: "^(.*\\.)*unsafe.tld$"}]
right: [%Regex{opts: [:caseless], re_pattern: {:re_pattern, 1, 0, 0, #Reference<0.378940835.3277193222.129649>}, source: "^(.*\\.)*unsafe.tld$"}]
stacktrace:
test/pleroma/web/activity_pub/mrf_test.exs:39: (test)
It is not possible match regexes anymore as this worked by accident
previously. Instead, at least check that the sources of the regex (the
regex itself) match.
Notice the +1 difference in the regex Reference below.
1) test to_elixir_types/1 complex keyword with sigil (Pleroma.ConfigDBTest)
test/pleroma/config_db_test.exs:460
Assertion with == failed
code: assert ConfigDB.to_elixir_types([
%{"tuple" => [":federated_timeline_removal", []]},
%{"tuple" => [":reject", ["~r/comp[lL][aA][iI][nN]er/"]]},
%{"tuple" => [":replace", []]}
]) == [federated_timeline_removal: [], reject: [~r/comp[lL][aA][iI][nN]er/], replace: []]
left: [federated_timeline_removal: [], reject: [%Regex{opts: [], re_pattern: {:re_pattern, 0, 0, 0, #Reference<0.230935836.591265794.259515>}, source: "comp[lL][aA][iI][nN]er"}], replace: []]
right: [federated_timeline_removal: [], reject: [%Regex{opts: [], re_pattern: {:re_pattern, 0, 0, 0, #Reference<0.230935836.591265794.259516>}, source: "comp[lL][aA][iI][nN]er"}], replace: []]
stacktrace:
test/pleroma/config_db_test.exs:461: (test)
