* rejected_shortcodes is defined as a list of strings in the
configuration description. As such, database-based configuration was
led to handle those settings as strings, and not as the actually
expected type, Regex.
* This caused each message passing through this MRF, if a rejected
shortcode was set and the emoji did not exist already on the instance,
to fail federating, as an exception was raised, swiftly caught and
mostly silenced.
* This commit fixes the issue by introducing new behavior: strings are
now handled as perfect matches for an emoji shortcode (meaning that if
the emoji-to-be-pulled's shortcode is in the blacklist, it will be
rejected), while still supporting Regex types as before.
Even though latest PleromaFE supports displaying these properly, mobile
apps still exist, so I think we should offer a workaround to those who
want it.
Mastodon uses the Reject activity also for the purpose of removing
a follower, in addition to reject a follow request. We should
also update the original Follow activity in this case.
Notes:
- QuestionValidator didn't have a :name field but that seems like a mistake
- `_fields` functions can't inherit others because of some Validators
- bto/bcc fields were absent in activities, also seems like a mistake
(Well IIRC we don't or barely support bto/bcc anyway)
* Policies were put under a new module (Pleroma.Web.ActivityPub.MRF.Policy instead of Pleroma.Web.ActivityPub.MRF), but this wasn't changed in the Pleroma.Web.ActivityPub.MRF @mrf_config_descriptions
* I don't have a unit test to prevent similar problems in the future because I don't find a proper way to do it
* The descriptions in the unit tests are defined in the unit tests, so if someone changes module names in the code, the tests wont see it
* The list is generated in Pleroma.Docs.Generator.list_behaviour_implementations, but I can't do a check in the when clause of the function to see if the provided module is a behaviour or not.
Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3509
* Policies were put under a new module (Pleroma.Web.ActivityPub.MRF.Policy instead of Pleroma.Web.ActivityPub.MRF), but this wasn't changed in the Pleroma.Web.ActivityPub.MRF @mrf_config_descriptions
* I don't have a unit test to prevent similar problems in the future because I don't find a proper way to do it
* The descriptions in the unit tests are defined in the unit tests, so if someone changes module names in the code, the tests wont see it
* The list is generated in Pleroma.Docs.Generator.list_behaviour_implementations, but I can't do a check in the when clause of the function to see if the provided module is a behaviour or not.
