New category permission - "cannot see"/"exclude"

Continuing the discussion from Suspend as way to expire membership:

After suggesting to another user that instead of suspending a user they could put them in a group and change category permissions. I recently came across my own use case for this, where I needed to add some users to my instance and only give them access to one category. It does not seem like there is an easy way to do so, without modifying the permissions for every other category, and putting all other users in their own group. Having the ability to say that membership in a group prevents viewing of a category would be very useful.


It would be great to be able to set security for content (in categories or groups) that allows admins to EXCLUDE rather than always include, as sometimes that definition IS that it is 'everyone who is NOT …" rather than “is”

(Logically they are not mutually exclusive)

Whereas now you can only use “CAN” (create/reply/see) it would be useful to also have “CAN’T” as an option in order to use an identifier for a defined group as a limiting factor.

For example:
This conversation group about Europe is for everyone but NOT those in the UK group
To achieve this it is easier to select EVERYONE then excluding UK, than to create a new group combining 27 other national groups


That could indeed be a chore.

Maybe instead

Make a Group eg. “Restricted” and add member(s) to it.
Create a Category with
everyone - Create, Reply, See
restricted - Create, Reply, See
Then make sure the member(s) of the restricted group do not belong to any other group that is being used by any of the other category Security settings.

Not sure how this is any different. We already have a category structure (over 10 categories) that all have “everyone” permissions. We need “everyone” but a few people to have permissions in all categories.

1 Like

Hi Joshua, this sounds like Slack’s Multi-Channel Guest and Single-Channel Guest user types, mentioned here: Permissions in Slack – Slack Help Center

and they work like this:

Multi-Channel Guest: " These accounts can only access selected channels, and they can start direct messages with the people in those channels. "

Single-Channel Guests: “This type of Guest account can only access a single channel and start direct messages with the people in that channel.”

Sounds to me you’re looking for Single-Channel Guest? Perhaps it’d make sense to add those user types — if they’re useful in Slack, then perhaps in Discourse too.

(Perhaps a tips, then, for Discourse developers or plugin creators, would be to have a look at how Slack has solved this :- ) )

1 Like

That is a very good analogy, thanks @KajMagnus. In this case I am looking for an “equivalent” to Slack’s single-channel guest.

1 Like

Scratch my idea.

For whatever reason I was thinking a member could be removed from the everyone group.

Not possible via the Admin -> User interface anyway.
I guess it might be possible using the CLI but it is much more likely to not be possible at all without major code rewriting

It’s not really possible anyways, as anonymous users belong to ‘everyone’.


Not with login required.


Is there any chance that the Security settings for categories might enable an admin to say who CAN’T access it rather than just who can?

For example;

  • Group A is All Users, and
  • Group B is a small group of specialists (e.g. invited guests),

the only way to create a category viewable ONLY to those in A who are not in B is to create a new Group that includes all users minus the very small number of guests

It is frustrating to have to work around this issue and to maintain new groupings which only exist for this purpose.

Is there a simpler workaround?

I’ve tried searching for previous posts on this subject but the terms are fairly general.

1 Like

Currently it is not possible. You may have to write a plugin.

I think this is an AB problem.

You want to invite these guests but not have them inundated with posts they don’t care about? It’s not so much that you don’t want them to be able to see them, right?

You can mute all the categories they don’t care about. You could do that pretty easily from the ratings console.

It depends on the scenario. Sometimes subtraction is easier. Sometimes addition is easier.

However have both is confusing and complies to setup.

1 Like

Actually no. The specific case I have in mind right now is that I have a small group of VERY active members who are too keen to reply to everything. When I post threads aimed to engage less active members it is immediately filled with their replies.

I could ask them to stop, but that is a difficult message.

What I’m doing is to have an onboarding group that includes all users, but NOT these members so they don’t see the content. It is not ideal, but it sort of works. However, if I could manage who is IN Group B so excluding a selection rather than maintaining Group A, it was be easier

I’m sure I could find plenty of similar examples

Not really. If you look at query builders in excel for example you have both ‘IS’ and ‘IS NOT’

1 Like

I see. That seems more like a community problem for @hawk than a technical problem.

I’m not an expert in such matters, but I think asking people to change their behavior, as difficult as it may be, seems preferable to hiding messages from them. Eventually they’ll find out and be unhappy/hurt/angry.

1 Like

You called?

I’m definitely all for finding ways to make the software do the work but I agree that this sounds like a behaviour change issue.

How about trying something simple first like posting one of your threads and making the messaging something like “We have a whole lot of new members on board these days and I’d love to hear their voices. Here’s a question for them. etc”

Then if the others answer you could respond with a light hearted "You are definitely not one of the new voices :wink: " . A few of those might start to get the message across.

It could simply be a case of them not realising what they’re doing.


I’m sure it is, but in practice it is a bit more complicated since it is also a gender issue (let’s say I’m trying to help one group ‘lean in’)

This is a specific issue though

As I said, it would be great to be able to set security for content that allows me to exclude rather than always include, as sometimes that definition IS that it is 'everyone who is NOT …" rather than is

(Logically they are not mutually exclusive)

What if I wanted to create a group to discuss why a percentage of my members did NOT attend an event? It follows that I can create a fixed list of who was there more easily than those who were not

1 Like

I hear ya.

Yup, I think there are potential use cases for this but I’m not sure there would be many.

1 Like

Maybe you could nudge behavior by taking advantage of the Like feature?

For example, if there are grades of expertise, eg.
Newbie, Literate, Fluent, Advanced, Guru
where each knows all of the previous, it could be discouraging for a Literate to help a Newbie after a Guru replied.

Rather than not allowing a Guru to reply to a Newbie topic, I think giving Likes to those less advanced but still more advanced than Newbie could help encourage them.

Ideally, the Guru would hold back long enough to give others a chance to be helpful and only jump on Advanced topics, but exclusion doesn’t feel like a good approach to enforcing that to me.

1 Like

I previously brought this up (wow, over a year ago now).

Since that topic, I had another use case where “cannot see”/“exclude” would have been useful.
In that case, we had an existing login_required site with 50+ categories. 45 or so of the categories has “everyone” permissions set. We had one category where we wanted to give some external contractors access. We only wanted them to see one category. With or without the “exclude” feature, we would need to modify all 45 category permissions. The problem is that we would need to add all existing users to a group so we could give that group permissions everyone, and put the contractors into a different group. That would work for all current users, but would not scale well after. Users don’t share a email domain, so we would need to manually add them to the group after registration. Having “exclude” would allow us to continue to use everyone permissions, but simply prevent the few contractors from accessing all categories without putting all other users in a group.


Of course that would also have the bad side effect of breaking all your badges because those 45 categories suddenly became private and not Everyone.

Flexible Security is really not one of Discourse’s design goals…

1 Like