Propose new functionalities for Decidim software
#DecidimRoadmap Designing Decidim together
Finished
Right now, all admin-users seem to receive message when inappropriate content is reported. This is annoying since most people with admin-privileges are not involved in moderation. The generated email message is also cryptic, instead of "resource reported" one could say something more descriptive e.g. "content on the website [instance name] has been reported as inappropriate, please check by following the link below". We have more and more admins now and the message is confusing.
The development of this proposal has finished
- Reviewed by @product and accepted in the main project
- Funded by Helsinki City Council
- Developed by Mainio Tech
- Available in release 0.24 via #7328
Report inappropriate content
Is this content inappropriate?
12 comments
Hi @katjah, this is indeed a good proposal.
Do you think it would be more appropriate that only admins of a particular process receive notifications about moderation of the contents of their process? I also agree to improve the email message.
As I see you've marked it as funding available, are you planning to send a PR to implement it?
Thank you @carol. For us, it would be ideal if any admin (system or process level) could define weather he/she wants moderation messages or not. However, limiting moderation messages to process admins would also be very helpful. We have not yet started to work on this but @ahu can implement this and make a PR if you agree.
Conversation with Antti Hukkanen
I suggest we would add a new notification setting in the user's personal notification settings under My account > Notification settings. This setting would obviously only be visible for users who are administrators OR are moderators in a participatory space (for participatory processes the users with the "collaborator" right and for any other participatory space all admins of that space).
This would allow the users to control themselves whether they want to get the moderation messages in case they have the right to moderate something.
Here's a mockup what the setting could look like:
https://i.snag.gy/RdXHOJ.jpg
Technically this would be a new boolean setting on the user model, e.g. `receive_moderation_messages`. By default, this setting would be enabled not to change the current behavior.
A thing to note here is that this leaves the responsibility for the single users to disable this setting. In case we want to allow admins to control who are receiving these notifications, I would suggest making all the notification settings controllable for by admins for every single user in the system.
This would be a completely separate feature that would need to be further discussed. This could be discussed along with this proposal:
Ability for admins to create new user accounts
In addition of the ability to add new users, the admins could also be able to edit the existing accounts (at least on some extent, like the notification settings).
Conversation with Carol Romero
We just discussed this feature yesterday with the @product team and thought of a possible solution (knowing that in the future we should rethink the administration panel to optimize it).
As we discussed with @katjah, the proposal is:
- That by default only admins and moderators of the space/process receive notifications where that content is reported.
- As Decidim is also used by small organizations, it is useful to have the option that all admins of the instance receive all notifications. To do this we would add a setting in the general configuration that allows to activate them. See a mockup here: https://www.awesomescreenshot.com/image/3952849/ccea9f66e9f762fe759823bc5772fa33
This would mean that the moderators need to be defined for each participatory space either with the general admin or collaborator role (in case of processes). This may add unnecessary work as I would believe that the moderators in Helsinki's case are specific people with admin accounts, not only admins of some space. And this can be rather confusing because for processes and assemblies the role is different, there WILL be unnecessary configuration mistakes.
Then this would leave the other question, what if there is a participatory space admin/collaborator who does not want to receive moderation messages?
I would still think allowing the individual people to control this would be more flexible and technically elegant solution + it would lead to less complexity regarding the general settings of the platform. And it would utilize a pattern already available.
I see your point but I'm worried about mixing settings for administrators in the participant interface.
My reasoning is as follows: in a large organization with many spaces, it is better to have specific admins for each space. Administrators (and moderators if there are any) should be notified about the activity that occurs in the spaces they manage. I don't think an admin can choose **not to receive notifications** about their space.
We can agree that the best solution would be to have in the admin panel a place where we can choose the options of the admins in the same line as the other proposal (Ability for admins to create new user accounts), but I understand that this is more complex and requires more discussion.
Again, my main concern is to mix admin and participant settings in the same interface.
In my opinion, this option is something that concerns the individual user accounts and therefore it should appear under the user's personal settings, not something that should be configured organization wide. Of course, it would be great if these settings could be also controlled by admins for other users but as you said - that would need more discussion and specification.
If the concern is mixing these settings with the settings that concern the participants, maybe a better way would be to add a separate "administrators" section under the notification settings like this:
https://i.snag.gy/CR931S.jpg
Also, in my opinion a bigger concern should be making the system more complex than adding more and more obscure settings that no one will understand. If this concern is still a major one, I would suggest first implementing this as I proposed and later on moving this setting to the admin panel once the user management feature is implemented there.
This way, it would not change anything in the technical backend of this setting but would just move the configuration to another UI. The technical elegancy of this approach.
For the optimizing admin panel part, I would also suggest not to make it more and more confusing and fix it later. The general direction would be to make it easier and easier to use all the time.
The checkbox settings in many places are already quite complex, for example in the proposals component it is possible to set "Supports enabled" and "Supports blocked" at the same time. This type of checkbox settings easily lead to this type of confusing patterns.
This would also support what I suggested above.
I do agree with @ahu that it would be best - both simple and flexible - just to allow individual admins to determine whether they want notifications or not. The setting could be "on" by default. We trust our employees that if they turn messages "off" they do it for a good reason. However, if this is not acceptable to rest of the Decidim community, the solution proposed by @carol is also ok for me. We currently do not use process level admins but I see we should start using them for other reasons as well. However, we will still have system level admins who need to receive moderation messages from all processes - then I need to configure all of them as process admins to each and every process, which means some extra configuration work and complexity. But I can live with that. :)
Ok, In order not to block this more than necessary, let's go ahead with @ahu's proposal to integrate this as a setting in the participant's notifications, and in the future we see how we rephrase this in the admin panel.
Add your comment
Sign in with your account or sign up to add your comment.
Loading comments ...