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.
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>
Otherwise this leaves it enabled if the processing failed, which then
makes other specs fail where they expect the image not being processed
(for example still have the initial set dimensions, instead of the one
read from image after processing).
This fix was heavily inspired by Mastodon's fix for GHSA-9928-3cp5-93fm.
So, thank you Cure53 for finding this issue, thank you Mozilla for
paying Cure53 to look into it, and thanks for Mastodon for fixing it.
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
Yes, I know this is a very ugly workaround, but it works ...
Chrome now requires to add `about:blank` as parameter to open and be
able to use remote debugging. The jasmine-gem isn't supported anymore,
and we need to switch to the `jasmine-browser-runner`, I was working on
that a few months ago, but ran into problems.
As the jasmine-gem doesn't allow to add parameters without `--` infront
of it, lets just add a dummy parameter and add the required
`about:blank` with a space after that. This is ugly, but works for now,
until we can upgrade to the new jasmine version. We could also just
replace the `nil` of the last parameter with that value, but I think
that way it's clearer that this is a workaround and how it works.
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.
The unique index doesn't work when the port is `NULL`. So use `-1`
instead for when using the default ports (80/443), as if we would use
the real ports, we could still have both 80 and 443 in the database at
the same time.
This URL is only used in the mobile UI, but when somebody then copies
the link and sends it to somebody on the desktop UI, they don't see
anything. So lets just redirect to the post containing the photo, so
there is at least something to show.
If there is no linked post, just redirect to the image instead.
Fixes#8352
Usernames that contained underscores were parsed by markdown first. This
broke the diaspora IDs and also added weird html at places where it
wasn't needed. Escaping them before sending the message through the
markdown parser fixes this issue.
As underscores are the only allowed character that can be used for
markdown that is also allowed inside a diaspora ID, this escaping can be
kept pretty simple.
This only fixes it for the mobile UI at the moment, for the desktop UI
it's probably better to fix it in markdown-it.
Related to #7975
