| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Document the changes for Varnish 7.0+ compatibility and RFC compliance
See merge request pleroma/pleroma!3723
|
|
|
|
Some software, like GoToSocial, expose replies as ActivityPub
Collections, but do not expose any item array directly in the object,
causing validation to fail via the ObjectID validator. Now, Pleroma will
drop that field in this situation too.
|
|
The (request-target) used by Pleroma is non-standard, but many HTTP
signature implementations do it this way due to a misinterpretation of
the draft 06 of HTTP signatures: "path" was interpreted as not having
the query, though later examples show that it must be the absolute path
with the query part of the URL as well.
This behavior is kept to make sure most software (Pleroma itself,
Mastodon, and probably others) do not break, but Pleroma now accepts
signatures for a (request-target) containing the query, as expected by
many HTTP signature libraries, and clarified in the draft 11 of HTTP
signatures.
Additionally, the new draft renamed (request-target) to @request-target.
We now support both for incoming requests' signatures.
|
|
|
|
Due to the lengthiness of this task, the migration has been adapted into
a BaseMigrator migration, running in the background instead.
|
|
`context` fields for objects and activities can now be generated based
on the object/activity `inReplyTo` field or its ActivityPub ID, as a
fallback method in cases where `context` fields are missing for incoming
activities and objects.
|
|
|
|
'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
|
|
Fix Varnish7 support
See merge request pleroma/pleroma!3722
|
|
|
|
|
|
capitalized HEAD verb
|
|
Incoming Pleroma replies to a Misskey thread were rejected due to a
broken context fix, which caused them to not be visible until a
non-Pleroma user interacted with the replies.
This fix properly sets the post-fix object context to its parent Create
activity as well, if it was changed.
|
|
These objects represent from 30 to 70% of the rows on the objects table,
based on numbers from a few live instances (single-user, small, large.)
As those pseudo-objects prevent creating objects with those actual IDs,
deleting them is a better solution. This could have happened if an
object used another object's ID as its context.
|
|
This field replaces the now deprecated conversation_id field, and now
exposes the ActivityPub object `context` directly via the MastoAPI
instead of relying on StatusNet-era data concepts.
|
|
|
|
|
|
This field seems to be a left-over from the StatusNet era.
If your application uses `pleroma.conversation_id`: this field is
deprecated.
It is currently stubbed instead by doing a CRC32 of the context, and
clearing the MSB to avoid overflow exceptions with signed integers on
the different clients using this field (Java/Kotlin code, mostly; see
Husky and probably other mobile clients.)
This should be removed in a future version of Pleroma. Pleroma-FE
currently depends on this field, as well.
|
|
|
|
30 to 70% of the objects in the object table are simple JSON objects
containing a single field, 'id', being the context's ID. The reason for
the creation of an object per context seems to be an old relic from the
StatusNet era, and has only been used nowadays as an helper for threads
in Pleroma-FE via the `pleroma.conversation_id` field in status views.
An object per context was created, and its numerical ID (table column)
was used and stored as 'context_id' in the object and activity along
with the full 'context' URI/string.
This commit removes this field and stops creation of objects for each
context, which will also allow incoming activities to use activity IDs
as contexts, something which was not possible before, or would have been
very broken under most circumstances.
The `pleroma.conversation_id` field has been reimplemented in a way to
maintain backwards-compatibility by calculating a CRC32 of the full
context URI/string in the object, instead of relying on the row ID for
the created context object.
|
|
|
|
|
|
Moderators were able to delete statusses via pleroma-fe. For that reason I now gave them :messages_delete by default.
They are also able to recieve reports through the notifications. For that reason I now gave them :reports_manage_reports by default.
They were also able to see deactivated accounts through pleroma-fe. However
* they were unable to tell if the account is deactivated or not (which was a bug and fixed by thes privileges MR this commit is part of)
* they were not able to actually change the activation state.
Because of this, I decided to *not* give them the privilege :users_manage_activation_state as this would give significantly more
privileges, while not giving it will actually improve the current experience as it works around the existing bug of not showing activation state.
|
|
|
|
|
|
|
|
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
|
|
Translations update from Pleroma Weblate
See merge request pleroma/pleroma!3716
|
|
Currently translated at 18.9% (189 of 998 strings)
Translation: Pleroma/Pleroma Backend (domain config_descriptions)
Translate-URL: http://weblate.pleroma-dev.ebin.club/projects/pleroma/pleroma-backend-domain-config_descriptions/zh_Hans/
|
|
Currently translated at 18.9% (189 of 998 strings)
Translation: Pleroma/Pleroma Backend (domain config_descriptions)
Translate-URL: http://weblate.pleroma-dev.ebin.club/projects/pleroma/pleroma-backend-domain-config_descriptions/zh_Hans/
|
