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
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 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.
When someone isn't a superuser any more, they shouldn't see the reporsts any more either.
Here we delete the report notifications from a user when that user gets updated from being a superuser to a non-superuser.
* These are the first small steps for issue 2034 "Reports should send a notification to admins".
* I added a new type of notification "pleroma:report" to the the database manually (a migration will need to be written later)
* I added the new type to the notification_controller
* I made the view return the notification. It doesn't include the report itself (yet)
tusooa
Mark Felder