It's enough to check if the comment exists on the specified post, if it
doesn't exist at all, that check will also fail.
Also do that check directly on SQL level and just check if the comment
exist instead of looping through all comments.
There is no need to load all comments only to count them. Lets just let
the database do all the work. If there are no comments found, nothing
will happen anyway.
Also already filter the comments to only search for notifications for
own comments.
And add some tests :)
Now with likes on comments, diaspora also tries to fetch comments if it
receives a like for a comment it doesn't know yet. So this now also
allows to fetch comments with `/fetch/comment/<guid>`.
When liking a comment, the post also gets a participation, and if all
likes/comments get removed again, the participation also gets removed
again.
The only thing still not working properly is the frontend, but that is
already broken when unliking a post. So it shows an invalids state in
the frontend when unliking the post/comment.
Due to historic reasons with a comment the list of all likes was sent to the frontend.
This is needed just to detect if one of the likes is current users like.
So if sending just the own like, the frontend can do it's job.
When the frontend is refactured in any way, post and comment like handling should be improved.
Adapt to latest development
User likes
Set css class for inline likes on comment
Re-set participation on comment likes
Co-authored-by: Thorsten Claus <ThorstenClaus@web.de>
Sidekiq 7 requires redis 6.2+, which isn't available in a lot of distros
yet :( So lets wait with this for a while.
This partially reverts commit a59505574a.
`deep_merge!` modifies the hash of the default translation, and it looks
like `I18n.t` always returns the same instance, so after that, the
default stays translated. So lets duplicate the hash first, before
modifying it, this also helps because we also add more keys below, which
probably also shouldn't be added to the original.
Some email providers (for example gmail) block emails if they have
emojis in the from header, as they could be confused with UI elements.
So the easy solution is to just filter all emojis from the name.
The normal `\p{Emoji}` selector also matches normal numbers, because of
the emoji-version of numbers (1️⃣), but the `\p{Emoji_Presentation}` then
doesn't match colored emojis anymore (❄️), so we need a mix of both to
find all emojis
There are no new releases anymore and the current version isn't
compatible with ruby 3.x.
As this feature wasn't really used a lot (Icelandic didn't even setup
inflections properly), it's probably not worth fighting for it, so lets
just drop it.
Related to #8369
Some imagemagick-versions (I tested Ubuntu 22.04 and debian bullseye)
always loose exif data when converting from jpg to webp. So this made
our CI fail now, but even if it wasn't failing before, some pods always
had and have versions which might loose the information anyway. So
having a setting to keep exif information is kinda pointless, if we
can't guarantee that the information isn't lost. Also, diaspora isn't a
photo sharing platform and we don't display exif information anywhere,
so I think we should just always strip exif data (which was already the
default before), as we don't need them.
