| Age | Commit message (Collapse) | Author |
|---|
|
During attachment upload Pleroma returns a "description" field. Pleroma-fe has an MR to use that to pre-fill the image description field, <https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1399>
* This MR allows Pleroma to read the EXIF data during upload and return the description to the FE
* If a description is already present (e.g. because a previous module added it), it will use that
* Otherwise it will read from the EXIF data. First it will check -ImageDescription, if that's empty, it will check -iptc:Caption-Abstract
* If no description is found, it will simply return nil, just like before
* When people set up a new instance, they will be asked if they want to read metadata and this module will be activated if so
This was taken from an MR i did on Pleroma and isn't finished yet.
|
|
|
|
I first focussed on getting things working
Now that they do and we know what tags there are, I put some thought in providing better names
I use the form <what_it_controls>_<what_it_allows_you_to_do>
:statuses_read => :messages_read
:status_delete => :messages_delete
:user_read => :users_read
:user_deletion => :users_delete
:user_activation => :users_manage_activation_state
:user_invite => :users_manage_invites
:user_tag => :users_manage_tags
:user_credentials => :users_manage_credentials
:report_handle => :reports_manage_reports
:emoji_management => :emoji_manage_emoji
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I didn't add it to /api/v1/instance
I was wondering if I should, but since it e.g. also didn't show staff, it felt better not to
|
|
I added an extra key
We already had is_admin and is_moderator, now we have an extra privileges key
|
|
Deactivated users are only visible to users privileged with :user_activation since fc317f3b17
Here we also make sure the users who are deactivated get the status deactivated for users who are allowed to see these users
|
|
Instead of `Pleroma.User.all_superusers()` we now use `Pleroma.User.all_superusers(:report_handle)`
I also changed it for sending emails, but there were no tests.
|
|
This should eventually replace the Pleroma.User.all_superusers/0 function
* I added a new param `is_privileged` in User.query
* Now we can fetch all users with a specified privilege
|
|
Everything now happens with privileged?/2
|
|
Before we deleted the notifications, but that was a side effect and didn't always trigger any more.
Now we just hide them when an unprivileged user asks them.
|
|
This reverts commit 89667189b840fc79d85336739e6b2512684d7be0 and cdc5bbe8369d4fc66d642bb3e845a237d11e34d7.
This is a side effect when changing user role.
The goal was to not have report notifications when someone isn't admin or moderator any more.
But this won't be triggered when we change the privilege tags for a role, so we can't use this sollution any more.
There was another solution to filter out report notifications during fetch.
It wasn't merged because this seemed 'cleaner' at the time, but now it seems the better sollution.
I'll add it in the next commit.
|
|
According to the tests, this was only used for unconfirmed accounts.
So this just needed to be restricted to users with privilege :user_activation
|
|
superuser
|
|
Instead of superusers, you now need a role with privilige :status_delete to delete other users statusses
I also cleaned up some other stuff I saw
|
|
This should eventually replace Pleroma.User.superuser?/1
|
|
Fixed the warning
[warning] Please change `clear_config([section], key: value)` to `clear_config([section, key], value)`
|
|
I still had three endpoints I didn't really know what to do with them. I added them under separate tags
* :instance_delete
* :moderation_log_read
* :stats_read
I also checked and these are the last changes done by MR https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3480/diffs this is trying to fix
|
|
|
|
It also allows to update a message, so it's not just deleting. I need a better name...
|
|
From the endpoints left to do, I believe these should be under :statuses_read.
These should be the last for that privilege for this MR
|
|
One of the things we do during the tests is change the config. But that's global state and different tests were interfering.
E.g. one test would set `clear_config([:instance, :admin_privileges], [:statuses_read])`, but while that runs, another test may
do `clear_config([:instance, :admin_privileges], [:user_invite])`. Now the code for the first test checks the setting, and it
finds `:user_invite` instead of `:statuses_read`.
Now the modules where this happens are marked to run synchronously, so they don't interfere with each other.
|
|
|
|
|
|
|
|
|
|
|
|
Everything that was done through this setting, can now be set by giving the proper privileges to the roles.
|
|
This was the last in :require_privileged_staff. I'll remove that in the next commit
|
|
I only moved the ones from the :require_privileged_staff block for now
|
|
|
|
|
|
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
|
|
|
|
|
|
get_create_by_ap_id_with_object() seems to fetch the old object.
Why this happens needs further investigation.
|
|
|
|
|
|
|
|
|
