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

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...)
1 Like

@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

SOLD!

:slight_smile:

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.

2 Likes

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.

4 Likes

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.

1 Like