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

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

I would like to support this. My use case - I have a group of “limited” users; I want them to be able to read most categories, but write only in one, let’s call it “starting cat.”.
I can of course use existing solution (and trust levels of course), but if I want to have more fine-grained permission system, it gets hectic.
Instead of setting up permissions like this:

display: everyone
post: everyone NOT greenhorns

I have to do something like this:

display: everyone
post: Group 1
      Group 2
 (...and basically each and every other group...)
reply: Group a
       Group b
(...and once again...)

@hawk this post was moved into #community when someone misunderstood my request

I think this appears to have some support enough to justify it moving to either #support or possibly #feature - do you agree?

@robmc, looks like Jeff recategorized this already. Unless I’ve misread this, your request is the same as mine (linked above, long before I joined the Discourse team). Do you mind if the topics are combined, or do you feel yours is different?

1 Like

Well, our use cases are similar, but our current proposed solutions look a little different

I don’t mind combining them at all, but I think that your original proposal was to have a single category for putting members into that would stop them being in ‘everyone’ but I would prefer to have logic in the security that allowed us to use “IS NOT” (or can’t / exclude) in the same way we use “IS” (or Can) as I think this would give more flexibility

They are similar issues, but not quite the same and it is possible that a single technical solution would address both, but I’m not sure. Happy to put them together to explore it though

I’m not precious … just wanting to help make this even better for everyone

So my usecase at the time was a single category that I needed to restrict access to, but the solution is the same as you suggested: an “exclude” or “not” security permission for categories.

1 Like



Happy to join forces in that case

1 Like

I wiki-ed the OP. Feel free to add/edit anything you’d like.

Having Add+Subtract moves the system into a whole range of potential conflicts requiring resolution. At the least, the order of putting in permissions will now be significant, and so there will necessitate a reorder function to move things up/down.

Otherwise, there is no way to resolve potential conflicts when a person:

  • is in more than one group
  • one group is permitted access
  • another group is denied access

EDIT: Or you can say Add always trumps Subtract, or vice versa. Nevertheless, it makes things very hard to understand.

Although I can understand the pain you’re going through in order to request this… I have tons and tons of groups and each category’s permissions list is like 15 long, just to do what you’re looking to do – that is, to exclude a particular group from access while opening to most others.


Indeed, the order will matter

Since all sites are currently like yours, it might be that the solution is to have two steps / sections … the first is the INCLUSION (which is the current context, so even if the change is made nothing is affected) where you build up a total population to view this, then a second step below would be the EXCLUSION which would remove a portion of those that matched certain criteria.


There is also a need for intersection, meaning that the permission is only for users with two or more groups set.

For example, Sales & USA ==> any user having both the group Sales and USA. Then this combo should have access to USA Sales Leads category. In other words, the group is the “intersection” of a number of groups. Currently, the permission system works on the “union” of listed groups.

This will solve neatly the common headaches of setting up permission with sub-categories (where in many cases, the users permitted into the sub-categories will only be among the ones permitted into the parent category). It is necessary because, in Discourse, sub-categories do NOT inherit permissions.


I as well would love an exclude option and maybe it can be relatively simple: just allow us to add a group to the security settings of a category and let us uncheck the See box.

Right now if I add a group to the category security settings, I am able to uncheck the Create and Reply boxes but not the See box. If I could so uncheck the See box, then the logic seems like it could be “if user belongs to any group that does not have See permissions, do not let the user see the category.”

Makes me wonder how conflicting permissions work right now: if a user belongs to group A and group B and group A can create topics in that category but group B cannot create topics, can the user create a topic in that category? In other words, which takes precedence?

I assume it works right now as in “if user belongs to any group that has X permission, then grant that permission to the user” but I’m not sure…I just tested and that seems to be the case.

Permissions are effectively cumulative, there’s no such thing as a conflict in that sense. The highest inherited permission always wins. I can be added to one group which lets me see a category, and also another which lets me contribute.

Why would you need to exclude a group unless you’ve also explicitly given access through another membership?

I think the simplest example would be to give see, reply, and create permissions to everyone and then add group X and uncheck see, reply, and create so that everyone can see, reply, and create in that category except for group X members.

How it might apply to me currently: I use Memberful as an SSO provider on Discourse and WordPress and I want to sell three packages, two of the more expensive with access to the forum and the lowest one with no access. However, I think they may still get access because of syncing accounts across SSO and so I want to limit their access so they can’t see any categories and maybe can just send me PMs. I think I can do it by adding group Y and group Z to all the categories and not everyone and that works because i dont have many groups, but I think if I had many, unchecking the box for See would be easier.