This implements fully_qualify_emoji/1, which will return the
fully-qualified version of an emoji if it knows of one, or return the
emoji unmodified if not.
This code generates combinations per emoji: for each FE0F, all possible
combinations of the character being removed or staying will be
generated. This is made as an attempt to find all partially-qualified
and unqualified versions of a fully-qualified emoji.
I have found *no cases* for which this would be a problem, after
browsing the entire emoji list in emoji-test.txt. This is safe, and,
sadly, most likely the sanest too.
Tries fully-qualifying emoji when receiving them, by adding the emoji
variation sequence to the received reaction emoji.
This issue arises when other instance software, such as Misskey, tries
reacting with emoji that have unqualified or minimally qualified
variants, like a red heart. Pleroma only accepts fully qualified emoji
in emoji reactions, and refused those emoji. Now, Pleroma will attempt
to properly qualify them first, and reject them if checks still fail.
This commit contains changes to tests proposed by lanodan.
Co-authored-by: Haelwenn <contact+git.pleroma.social@hacktivis.me>
I used keyword_list[:key], but if the key doesn't exist, it will return nil. I actually expect a list and further down the code I use that list.
I believe the key should always be present, but in case it's not, it's better to return an empty list instead of nil. That way the code wont fail further down the line.
During attachment upload Pleroma returns a "description" field. Pleroma-fe has an MR to use that to pre-fill the image description field, <https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1399>
* This MR allows Pleroma to read the EXIF data during upload and return the description to the FE
* If a description is already present (e.g. because a previous module added it), it will use that
* Otherwise it will read from the EXIF data. First it will check -ImageDescription, if that's empty, it will check -iptc:Caption-Abstract
* If no description is found, it will simply return nil, just like before
* When people set up a new instance, they will be asked if they want to read metadata and this module will be activated if so
This was taken from an MR i did on Pleroma and isn't finished yet.
Tries fully-qualifying emoji when receiving them, by adding the emoji
variation sequence to the received reaction emoji.
This issue arises when other instance software, such as Misskey, tries
reacting with emoji that have unqualified or minimally qualified
variants, like a red heart. Pleroma only accepts fully qualified emoji
in emoji reactions, and refused those emoji. Now, Pleroma will attempt
to properly qualify them first, and reject them if checks still fail.
