Age | Commit message (Collapse) | Author |
|
'develop'
Treat MRF rejects as success in Oban worker
Closes #2912
See merge request pleroma/pleroma!3720
|
|
'develop'
Fix flaky tests with DB connections; Allow higher amount of restarts for Pleroma.Repo during testing
See merge request pleroma/pleroma!3696
|
|
Synchronized settings for apps (frontends)
See merge request pleroma/pleroma!3698
|
|
Backport: bugfix/follow-state
Closes #2902
See merge request pleroma/pleroma!3718
|
|
capitalized HEAD verb
|
|
|
|
|
|
Reviewed-on: https://akkoma.dev/AkkomaGang/akkoma/pulls/104
|
|
local only fixes
Closes #2871
See merge request pleroma/pleroma!3660
|
|
Allow users to create backups without providing email address
See merge request pleroma/pleroma!3665
|
|
# Conflicts:
# CHANGELOG.md
# test/pleroma/user_test.exs
|
|
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
|
|
Emoji: implement full-qualifier using combinations
See merge request pleroma/pleroma!3709
|
|
Make mutes and blocks behave the same as other lists
Closes #2384
See merge request pleroma/pleroma!3693
|
|
Behavior matches previous code.
Co-authored-by: Tusooa Zhu <tusooa@kazv.moe>
|
|
|
|
|
|
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>
|
|
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
|
|
|
|
Document way to do notice compatibility routes with Nginx reverse-proxy, fixes #2900
Closes #2900
See merge request pleroma/pleroma!3701
|
|
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
|
|
Translatable config descriptions
Closes pleroma-meta#65
See merge request pleroma/pleroma!3695
|
|
|
|
MastoAPI: Use `types` for filtering notifications
See merge request pleroma/pleroma!3648
|
|
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
|
|
|
|
|
|
This was done by floatingghost as part of a bigger commit in Akkoma.
See <https://akkoma.dev/AkkomaGang/akkoma/src/commit/37ae047e1652c4089934434ec79f393c4c839122/lib/pleroma/application.ex#L83>.
As explained in <https://ihatebeinga.live/objects/860d23e1-dc64-4b07-8b4d-020b9c56cff6>
> there are so many caches that clearing them all can nuke the supervisor, which by default will become an hero if it gets more than 3 restarts in <5 seconds
And further down the thread
> essentially we've got like 11 caches (https://akkoma.dev/AkkomaGang/akkoma/src/commit/37ae047e1652c4089934434ec79f393c4c839122/lib/pleroma/application.ex#L165)
> then in test we fetch them all (https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/test/support/data_case.ex#L50) and call clear on them
> so if this clear fails on any 3 of them, the pleroma supervisor itself will die
How it fails?
> idk maybe cachex dies, maybe :ets does a weird thing
> it doesn't log anything, it just consistently dies during cache clearing so i figured it had to be that
> honestly my best bet is locksmith and queuing
> https://github.com/whitfin/cachex/blob/master/lib/cachex/actions/clear.ex#L26
> clear is thrown into a locksmith transaction
> locksmith says
> >If the process is already in a transactional context, the provided function will be executed immediately. Otherwise the required keys will be locked until the provided function has finished executing.
> so if we get 2 clears too close together, maybe it locks, then doesn't like the next clear?
|
|
|
|
|
|
|
|
Add short_description instance field
Closes #2865
See merge request pleroma/pleroma!3651
|
|
|
|
into 'develop'
Make checking blacklisted domains and restricted nicknames case-insensitive
Closes #2894 and #2888
See merge request pleroma/pleroma!3687
|
|
|
|
Pass remote follow avatar into media proxy
Closes #2830
See merge request pleroma/pleroma!3690
|
|
|
|
do restricted nickname validation in LDAP account registration
|
|
|
|
Use EXIF data of image for image description
See merge request pleroma/pleroma!3535
|
|
Bugfix: Validate mediaType only by it's format
See merge request pleroma/pleroma!3597
|
|
Server announcements (1st pass)
See merge request pleroma/pleroma!3643
|
|
I noticed that pictures taken with Ubuntu-Touch have whitespace in one of the fields
This should just be ignored imo
|