We are trying to find some time to look into it. I’ll remove this warning after a fix is released.
Feature Request for Discourse
A Feature request to incorporate these functions is open here. Feel free to support it, if you think it would be useful to include these changes in the code Discourse functionalities.
Features
Since we started using discourse we found the actions available to category moderators to be lacklustre. Most basic content actions are limited (Set slow mode, add staff colour/notice, etc) when there isn’t really a reason in our opinion.
Thus we decided to try our hand and create a plugin that would grant most of the content-related moderation powers to category moderators, when they are in the category they have been assigned to.
These are the only exclusions:
Category Moderators cannot act on users - Suspend, Silence, change TL, access admin view on users are still reserved to regular moderators
Grant Badges - This is purely a internal choice. We thought that badges should be something special to obtain and give access to that to lots of moderators could risk trivialize the reward.
Change ownership of posts - We can’t see a use case for this function in our community so we simply left that out of the category moderators abilities.
Warning
If trying to access the Moderation History when there are no elements in the queue, you will receive a 403 error. It’s how discourse behave, nothing we could do about it as far as we’ve seen.
Currently there is a conflict with the component Restrict Edit Category.
We are looking into it but currently it is necessary to turn it off if you install this plugin.
Configuration
Simply install the plugin as you’ll do for any other and click the checkbox in the settings to turn it on.
CHANGELOG
Initial Beta Release
TODO
Allow optionally to act on Users
Allow optionally to allow full access (including badges and ownership change at the moment)
You don’t see the reason at all, or for your instance?
We sometimes use it on meta. For example, if a plugin or a theme/component originally developed by someone who doesn’t work on it anymore is transferred to someone else, then we change the author to the new maintainer, or to @system, depending on the context.
Clearly I worded it badly. Fixed now. In the TODO in fact is the possibility to enable that feature as an option.
In our community, that would simply become a wiki post so that everyone can contribute on it. It makes sense in the example you specify but for our forum, the only close case would be a guide for something (self hosting something using raspberry-pi, a guide to a game, a list of events for a band, etc etc)
Here’s an example use case: with the WordPress plugin, users need to be individually configured with a Discourse username — even if SSO ensures they are 1:1. If someone forgets or misconfigures the WordPress side, the post ends up owned by “system”.
Having WordPress moderators be category moderators for the blog comments category would let them take care of this (and, of course, moderate comments).
TL4 are forum wide. In our mind, a category moderator should have access to all tools a moderator has but restricted only by the category itself.
It’s a personal opinion but it really don’t make sense to us that users with an high TL have more power than category moderators when it comes to moderate a category.
TL4 in my opinion are good as they are as they can actually moderate forum wide but not act on users.
They are basically trusted users, recognized by the community to protect and foster it, without the risk of having them go nuts one day on other users account.
Category moderators, again, in our views, should be able to do what a moderator does, but in their own category. This include even banning people but that is on an entire other level of complexity.
What I was thinking is creating a group of users like “banned_from_categoryslug”, that category get assigned with read only to the category and the users added to that.
Alternatively, just extend users using the dedicated table in the db in which you add a user_id, category_id and a datetime. Every time a user access a topic, a check is run to see if he can actually interact with it or not.
The benefit of going for a group-based route is that there is a form of UI already implemented for admins and forum moderators to eventually lift a ban. The other approach would require to also develop a dedicated view but would allow for more flexibility (see ban expirations, etc)
I’m not sure this is a direction that Discourse want to go in, but if category moderators had this kind of power, it would open up the possibility of using categories as forums within a forum. That would be great from my point of view.
I believe Group Owners can remove people from the group, which would then remove their access to the category (if group-restricted). So perhaps a combination of group owner + category moderator would work for this?
Given the statement “these are the only exclusions”, everything on Trust Level Permissions Table (inc Moderator Roles) where the Category Moderator column says “TL” or is blank would turn to , except granting badges, changing ownership, and user-account actions.
I’d really love to see this have more granular control — or better yet, for that granular control to be not a plugin but baked in. For me, lack of the ability to change ownership (ironically one of the exclusions, I know), is the big deal — but obviously not for everyone.
This can work indeed. I have created a setup using this model and was apart of the html/markdown topic on the Display message if cannot post. To have it generate the message with a link to message group owners.
While this works a better option would be to add a ban\silence list option with time options to group owner. A problem user can then be banned from a group access category. While having an option to keep group unrestricted to join leave. Even in a restricted group this listing could maybe be extended to a notify user has a ban from group with ban note.
Note We could likely start a feature request to extend group functions to enable a reddit like subforum system using category mods… as @simon seems to have an interest as well.
Believe me, I would love that as well from Discourse itself. It’s been incredibly annoying to have someone work on the style of the forum but having to test the changes myself because I couldn’t just give FULL ADMIN to a person that was supposed to work just on css and visuals.
We can look into this. Admittedly something that we simply neglected because we didn’t think of an application (regular forum-wide moderators can do that eventually)
Overall, I would gladly retire this plugin if Discourse implemented a more granular control and would love for category moderator to be able to ban people from their category only, but alas, it doesn’t seem a priority or something they are interested in at this time.
Might be an idea for me or someone else start the extending groups.
ie
Suspend/ban List for Group Owners. Handy in. free to join & Req to join. Would need duration option. This ectension would work to further redditish theme parity.
New Revise option for queued posts
Moderators can now select “Revise…” as an option when reviewing posts queued for approval. A PM will be sent to the user with the reason for requesting a revision and optional comments so they have an opportunity to improve their post when they resubmit it.
Did something more than just add a new option because the plugin stopped working. It’s not breaking discourse as far as we can see, but the additional options are not available any more. It’s always fun when someone decide to refactor lots of stuff on top of adding a single new feature
We are trying to look into the code again to figure out what has been changed.
My understanding was that someone from the devs or close to them said that it wasn’t a priority / direction in which they were intending to go but maybe I am mistaken. I’m just passing by now, if anyone want to open the feature request, feel free to cross-link this topic so it appears in the links at the top or @ me and I will update the first post.
, except granting badges, changing ownership, and user-account actions.
