Category Moderators Enhancer

:information_source: Summary Allow most moderator level actions for category moderators
:hammer_and_wrench: Repository Link Github
:open_book: Install Guide How to install plugins in Discourse


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.


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.


Simply install the plugin as you’ll do for any other and click the checkbox in the settings to turn it on.


  • Initial Beta Release


  • 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).

Is this big use case here that you want category moderators not to be tl4 ?

I am very open to simply improving core here


I, at least, would like to make a distinction between:

  • recognized by a discussion community as a responsible, productive, constructive participant, and
  • has responsibility and power over a certain area by virtue of role (a role possibly entirely unrelated to general participation in discussion)

TL3 is an automated version of the former, and TL4 seems to me kind of like the “you’ve got tenure!” version of that.

Category moderator is (or should be!) perfect for the latter.


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)


So, what benefits are added?

Moving topics to other categories controlled by the group?
Reviewing flag queue?

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?


Could you please clarify exactly what this changes for Category Moderators. Thank you so much.

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 :white_check_mark:, 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.


100% agree. :heart:

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.