When reacting with different custom emojis with the same shortcode, it would count as an already present reaction and processed, bypassing the limit.
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
Instead of processing tag and then look for the custom emoji, let the processing return an emoji.
Add `name` to `process_emoji_tags` to check if it matches the shortcode.
Removed `process_single_emoji` and added its code to `process_emoji_tags`
Removed arg from `maybe_process_misskey_reaction`.
Ideally, `original_status` should be a global object, but I wanted to modify vanilla code as little as possible.
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
Handling remote reactions with foreign emojis would require an extensive rewrite of vanilla code, so instead prevent reactions with remote emojis when the status is not local.
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
When an account and a remote account reacted with a custom emoji with the same shortcode, the `me` attribute was also true for the remote reaction, despite being a different emoji.
This query should probably be optimised, but it works.
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
Right now Misskey users were able to react, but couldn't remove their reactions.
delegates `Undo` for a `Like` to `undo_emoji_react` when there is no favourite found.
(Misskey `Like` activities can still create a fav when the emoji tag is invalid, I don't see the point though)
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
Processing all custom emojis is neither wise nor necessary as both `Like` and `EmojiReact` only expect a single custom emoji
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
These occur when an account tries to react with disabled custom emojis.
In both `EmojiReact` and `Like? activities, the activity is discarded.
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
