Everyone permissions + "See" permissions

[outofthebox (Carson)]

Hi,

Our Discourse community has a public area that any registered member can participate in. However, I would like to be able to add some members to a group that effectively Silences them from that particular category. However, they would be able to participate in other Categories. What permissions in the Security tab need to be enabled to make it possible to restrict members of one group from creating/replying in a Category while allowing every other registered member to participate?

[robmc (Robert McIntosh)]

It is not possible to use security to “Exclude” a group of users, only to “Include”, so to achieve this you would need to create a group that would include all users except for the group you do not want to have access.

See these previous topics:

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 grou…

Rate-limit first-responders in specific categories

Continuing the discussion from Thoughts from the Elm community on Intentional Communication and “The Hard Parts of Open Source”: [26] Very interested to hear similar stories from other communities and how you did or couldn’t address them. All I know for sure is that this would have to be category-specific because in a category like our support there’s very little wrong with being a frequent first-responder.

[hellekin]

Since @robmc mentioned this topic in Everyone permissions + "See" permissions, let me add a resource to this discussion from Caucus groups:

The standard access levels are:

Keyword	Value		Description
organizer	40		Full management powers for whatever the group is used in
instructor	30		(limited organizer powers)
include	20
readonly	10
exclude	0		No access
inherit	-1		Inherit actual access level from subgroup

So that means you can actually put groups in groups, and exclude groups from certain things, creating a complex – or complicated – way to look at things. IMO this is a bit too fancy, and group exclusion should be enough: THIS permissions if IN GROUP X BUT NOT IN GROUP Y.

[Stephen]

Discourse denies by default, with explicit permissions to see, reply and create. You can achieve pretty much any outcome if users are grouped by role or purpose.

Rather than talking about silencing users, tell us what differentiates the two groups:

• How are they arriving on your system?
• How are they identified?
• Do you use SSO or any form of idm?

If you’re able to identify this group to silence, is it any less practical to have a ‘see’ by default and instead identify and group the users you want to create and respond?

[hellekin]

I think the issue is that one or more users are in one or more groups that intersect.

[Stephen]

Sure, so they aren’t the groups which grant that right. If there’s a need for a different security partition there’s a need for a different group.

[outofthebox (Carson)]

Hi Robert,

Thanks for the quick answer. It looks like this is not supported, which is fine. All software has limits.

You did mention:

you would need to create a group that would include all users except for the group you do not want to have access.

Is there a way, in the core functionality of Discourse, to do this? Or is this plugin territory?

[Stephen]

There’s no native way to maintain a group with all users except for those in another group within Discourse, but as you didn’t answer the questions asked above you might end up baking something yourself, or have to do it the old-fashioned way.

[outofthebox (Carson)]

Hi Stephen,

Interesting questions. It would be a pretty substantial change to limit our main forum to ‘see’ only, and then to identify and group the users who can create and respond. I think the simplest answer, given that this isn’t how Discourse works, is to simply ask this small group of users to refrain from participating in the main categories.

[Stephen]

Without knowing more yes, it probably is.

Without knowing the criteria to be a member of either group, we can’t really help you with any technology-based solutions.

[D8vid]

I’ve been reading many topics on this issue, and have a use case where the ability to exclude a group from access (e.g. to a category) would be most useful, in this fashion:

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

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. [exclude]

The use case is a Discourse instance dedicated to a fan community (for a multi-book & multi-season TV production) where ‘spoilers’ are an issue; members would like the ability to opt-out of seeing topics belonging to categories that are likely to contain spoilers.