Category Ban is not supported but would it be possible with a plugin?

I’ve read this topic which basically state that it’s not a feature seen as needed so I’m not going to ask for it again.

However, there are use cases for large communities like mine in which we have literally smaller forum existing inside the main one. Think about Clans in gaming culture.

These sub-communities adopt the main rules of the board but then have also some specific additional rules and a dedicated team that is meant to moderate the section as well as leading them but that’s beside the point.

Category moderators cannot act on the Users themselves, only on the category, however they should, in my use case, be able to impede some users from participating if they break some of their sub-forum rules.

All I need really is to know if there could be enough granularity in the core functions to allow the category moderators to block specific users from accessing their category.

The way I can imagine it, is that a custom table is generated that add both the category_id and user_id and when a user try to access a specific topic or category, simply check on that table as well.

Am I way off target? Would that be feasible? I’ve plenty of experience in software development but close to nothing with Ruby so I don’t really know where to start looking into Discourse source code to understand where should I look into :weary:

1 Like

You could allow only members of the clan category to post and remove the users you don’t want to be in the category. This would require that everyone that you want in the category to be a member of that group.


Great Topic for discussion.

Simplest way to solve this is Trust Level.

Knock people down when they need “banning”, and make the Category require High Trust.

Have had exactly this situation recently and simply locked the user at TL 1, the Category required TL 2. Job done!


I’ve done same-same. And because I don’t let anyone get automatically higher than TL2 that was mentally and for administration really easy and un-complex solution. There was a hint of of elegance too :wink:


I did this for a client a while back. Trust levels weren’t going to work for us, so instead we created private groups per-category which each user was automatically provisioned into, and category moderators were owners of.

“Bans” were as simple as removing said memberships which meant zero work on behalf of the administration.

Slightly more effort to get started, but effectively zero thereafter.


But how do you do that if the group is dynamic?

Example: one of my clients has a forum with a “For Sale” category, accessible for TL2 and up.
They want to ban certain members from creating topics there, but they would need to copy and maintain a group which contains the same people as TL2 minus 5 specific users.


Presumably the same way, provision users into groups based on a criteria (detect promotion to TL2?) then remove them if necessary? Just because TL2 is the entry criteria doesn’t mean that you need to rely on that TL2 status to determine membership, does it? It also depends whether you have the time and resources to engineer something on/around your instance.

I didn’t suggest it was a one-stop solution for all. It may not work for their use case if they don’t want to do the extra work, but for the example with my client and the scenario where an instance is being partitioned into guild/clans/whatever it could be a good fit.

1 Like

But if we’re engineering something on the instance anyway, then I’d rather have category ban functionality :sunglasses:

It makes things also more maintainable. If I have 50,000 users and I need all of them to be able to access the category but a few, then it’s hard to get a list of those few.

1 Like

I mean, ban is just another word for exclusion, and Discourse doesn’t really have an exclude permission at all. Does it need to exist when ‘not inclusion’ is effectively the same thing? I like the explicit permit model, it makes troubleshooting stuff painless.

I still have the odd nightmare about trying to resolve the permit/deny model from vBulletin all those years ago. The only thing I’ve experienced with more associated pain and debt is RSOP.

I appreciate all the input for alternative solutions but I asked a specific technical question, not alternative that are compromises to what I’m trying to figure out :slight_smile:


I would say yes

@crius it would be doable with a plugin, I think you can get pretty far on the client side by overriding the permissions in the category serializer, and on the server side adding an extra check using NewPostManager.add_handler.


Have you considered using groups? Create category with 2 groups for access. 1 Group is your category Mods. the Other is your participants in the subforum. The participant group is required to request access to Subforum area. Your cat mods some or all are owners of that group. If a member breaks rules requiring to kick them from sub firum. Kick from participant group and communicate with other cat mods on duration.

Well then unfortunately you may need to look into sponsoring a plugin. This is where crowd funding plugins would be a great concept. The core team may eventualky add something like your requesting bit it maybe sometime due to priorities development list.

On the otherside though with group suggestion it might be possible with a theme component to add a kick from group option.

Are you totally sure you asked right question :wink:

I’m meaning your primary goal is to solve out one issue, and category ban is just yours unsolved answer for that. The right question would be how do I solved issue X and what are my options.

1 Like

I evaluated the possibility of managing this with TL or users groups but it’s going to increase the workload on moderators which is simply not feasable on big communities.

The user groups especially is detrimental for a lean user experience.

I don’t need to ask for a sponsorship as I’ve plenty of experience as software engineer and other people that have plenty of experience as well. We simply don’t use Ruby so that will be the only slowdown.

Thanks for the inputs anyway. I appreciate that this forum tend to be very opinionated but when it comes to the software itself, it would be better to simply follow an approach that is more “give the option” with of course additional complexity code-wise being on the other side of the scale.

Much love to @RGJ for adding some insight :heart: