| Age | Commit message (Collapse) | Author |
|---|
|
Make mutes and blocks behave the same as other lists
Closes #2384
See merge request pleroma/pleroma!3693
|
|
|
|
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MastoAPI: Show mutes expiration date
See merge request pleroma/pleroma!3682
|
|
This reverts merge request !3684
|
|
|
|
Allow to unset birthday
See merge request pleroma/pleroma!3702
|
|
EmojiReactValidator: fix emoji qualification
See merge request pleroma/pleroma!3684
|
|
|
|
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
|
|
|
|
MastoAPI: Use `types` for filtering notifications
See merge request pleroma/pleroma!3648
|
|
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
|
|
|
|
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
|
|
Add short_description instance field
Closes #2865
See merge request pleroma/pleroma!3651
|
|
|
|
|
|
Pass remote follow avatar into media proxy
Closes #2830
See merge request pleroma/pleroma!3690
|
|
|
|
|
|
It used a timer to sleep.
But time also goes on when doing other things, so depending on hardware, the timings could be off.
I slightly changed the tests so we still test what we functionally want.
Instead of waiting until the cache expires I now have a function to expire the test and use that.
That means we're not testing any more if the cache really expires after a certain amount of time,
but that's the responsability of the dependency imo, so shouldn't be a problem.
I also changed `Pleroma.Web.Endpoint, :http, :ip` to `127.0.0.1` because that's the setting people typically have,
and I see no reason to do it differently.
Especially since it's an exernal ip, which may come over as weird or suspicious to people.
|
|
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
|
|
|
|
It is possible for an earlier Update to be received by us later.
For this, we now
(1) only allows Updates to poll counts if there is no updated field,
or the updated field is the same as the last updated date or
creation date;
(2) does not allow updating anything if the updated field
is older than the last updated date or creation date;
(3) allows updating updatable fields otherwise (normal updates);
(4) if only the updated field is changed, it does not create
a new history item on its own.
|
|
These changes make the encoding for the fully-qualified heart emoji very visible in editors.
|
|
In Create validator we do not validate the object data,
but that is because the object itself will go through the
pipeline again, which is not the case for Update. Thus,
we added validation for objects in Update activities.
|
|
|
|
# Conflicts:
# lib/pleroma/constants.ex
|
|
Bugfix: Validate mediaType only by it's format
See merge request pleroma/pleroma!3597
|
|
Server announcements (1st pass)
See merge request pleroma/pleroma!3643
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
get_create_by_ap_id_with_object() seems to fetch the old object.
Why this happens needs further investigation.
|
|
|
|
|
