Commit graph

14993 commits

Author SHA1 Message Date
Ilja
4a9ed319b8 Change test pictures
The previous pictures were labeled as public domain, but are actually a collage of pictures under other licenses.

I now replaced them with a jpeg of simply a white pixel.
2022-07-01 12:15:02 +02:00
Ilja
7d234d097c Add option to docs about instance gen 2022-07-01 12:15:02 +02:00
Ilja
81afaee374 Better way of getting keys
I used keyword_list[:key], but if the key doesn't exist, it will return nil. I actually expect a list and further down the code I use that list.
I believe the key should always be present, but in case it's not, it's better to return an empty list instead of nil. That way the code wont fail further down the line.
2022-07-01 12:15:02 +02:00
Ilja
75ea766824 Migration failed when no value for Pleroma.Upload was set 2022-07-01 12:15:02 +02:00
Ilja
cc5686bbd6 Migration for exiftool filter
Rename to Exiftool.StripLocation
2022-07-01 12:15:02 +02:00
Ilja
d0d48a9e88 Add deprecation warnings 2022-07-01 12:15:02 +02:00
Ilja
8303af84ce Rename the Exiftool module
No migrations or checks yet
2022-07-01 12:15:02 +02:00
Ilja
551721e41a Rename the new module 2022-07-01 12:13:46 +02:00
Ilja
cd316d7269 Use EXIF data of image to prefill image description
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.
2022-07-01 12:13:46 +02:00
Ilja
0d697bc15a Add docs and CHANGELOG entries 2022-07-01 10:50:32 +02:00
Ilja
37fdf148b0 Rename privilege tags
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
2022-07-01 10:28:09 +02:00
Hélène
11f9f2ef27
EmojiReactValidator: fix emoji qualification
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.
2022-06-28 21:33:57 +02:00
Tusooa Zhu
014096aeef
Make outbound transmogrifier aware of edit history 2022-06-25 11:20:46 -04:00
Tusooa Zhu
5321fd0012
Do not put meta[:object_data] for local Updates 2022-06-25 10:03:19 -04:00
Tusooa Zhu
9c6dae942d
Fix local updates causing emojis to be lost 2022-06-25 09:23:09 -04:00
Tusooa Zhu
e98579b1da
Verify that formerRepresentation provided in Update is used 2022-06-25 01:17:09 -04:00
Tusooa Zhu
40953a8f5c
Reuse formerRepresentations from remote if possible 2022-06-25 01:03:46 -04:00
Tusooa Zhu
99a6f50316
Unify the logic of updating objects 2022-06-25 00:32:22 -04:00
Tusooa Zhu
e0d6da4e7d
Fix CommonAPITest 2022-06-24 10:54:11 -04:00
Tusooa Zhu
ee07383191
Use meta[:object_data] in SideEffects for Update 2022-06-24 10:28:58 -04:00
Tusooa Zhu
01321c88b5
Convert incoming Updated object into Pleroma format 2022-06-24 10:25:22 -04:00
Tusooa Zhu
06da000c5d
Add editing to features 2022-06-21 12:32:44 -04:00
Ilja
4e4eb81749 Add nodes and privileges to nodeinfo
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
2022-06-21 12:10:27 +02:00
Ilja
211e561e2a Show privileges to FE
I added an extra key
We already had is_admin and is_moderator, now we have an extra privileges key
2022-06-21 12:10:27 +02:00
Ilja
143ea7b80a Add deactivated status for privileged users
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
2022-06-21 12:10:27 +02:00
Ilja
e21ef5aef3 report notifications for privileged 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.
2022-06-21 12:10:27 +02:00
Ilja
34adea8d28 Add Pleroma.User.all_users_with_privilege/1
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
2022-06-21 12:10:27 +02:00
Ilja
a1c8aa4721 Remove function superuser?
Everything now happens with privileged?/2
2022-06-21 12:10:27 +02:00
Ilja
eab13fed3e Hide pleroma:report for non-privileged users
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.
2022-06-21 12:10:27 +02:00
Ilja
e45faddb38 Revert "Delete report notifs when demoting from superuser"
This reverts commit 89667189b8 and cdc5bbe836.

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.
2022-06-21 12:10:27 +02:00
Ilja
edf0013ff3 User.visible_for/2
According to the tests, this was only used for unconfirmed accounts.
So this just needed to be restricted to users with privilege :user_activation
2022-06-21 12:10:27 +02:00
Ilja
bb61cfee8d Validator for deleting statusses is now done with priviledge instead of superuser 2022-06-21 12:10:27 +02:00
Ilja
7cf473c500 delete statusses is now privileged by :status_delete
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
2022-06-21 12:10:27 +02:00
Ilja
7adfc2e0f4 Add Pleroma.User.privileged?/2
This should eventually replace Pleroma.User.superuser?/1
2022-06-21 12:10:27 +02:00
Ilja
9da81f41c6 Fix warning during test user_test.exs
Fixed the warning
    [warning] Please change `clear_config([section], key: value)` to `clear_config([section, key], value)`
2022-06-21 12:10:27 +02:00
Ilja
c842e62675 Add last priviliges
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
2022-06-21 12:10:27 +02:00
Ilja
ecd42a2ce1 Add privilige :emoji_management 2022-06-21 12:10:27 +02:00
Ilja
0ee8f33250 Add privilige :status_delete
It also allows to update a message, so it's not just deleting. I need a better name...
2022-06-21 12:10:27 +02:00
Ilja
34a98990db last off :statuses_read
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
2022-06-21 12:10:27 +02:00
Ilja
4cb0dbb5dc Mark relevant tests synchronous
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.
2022-06-21 12:10:27 +02:00
Ilja
cbb26262a5 Add privileges for :user_read 2022-06-21 12:10:27 +02:00
Ilja
3f26f1b30f Add privileges for :report_handle 2022-06-21 12:10:27 +02:00
Ilja
14e697a64f Add privileges for :user_invite 2022-06-21 12:10:27 +02:00
Ilja
e102d25d23 Add privileges for :user_activation 2022-06-21 12:10:27 +02:00
Ilja
cb60cc4e02 Add privileges for :user_tag 2022-06-21 12:10:27 +02:00
Ilja
5a65e2dac5 Remove privileged_staff
Everything that was done through this setting, can now be set by giving the proper privileges to the roles.
2022-06-21 12:10:27 +02:00
Ilja
b1ff5241c2 Add priviledges for :statuses_read
This was the last in :require_privileged_staff. I'll remove that in the next commit
2022-06-21 12:10:27 +02:00
Ilja
8a9144ca8b Add priviledges for :user_credentials
I only moved the ones from the :require_privileged_staff block for now
2022-06-21 12:10:27 +02:00
Ilja
9f6c364759 Add privilege :user_deletion 2022-06-21 12:10:27 +02:00
Ilja
5b19543f0a Add new setting and Plug to allow for privilege settings for staff 2022-06-21 12:10:26 +02:00