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.
Suggestion:
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
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.
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 :- ) )
For whatever reason I was thinking a member could be removed from the everyone group.
Duh!
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
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.
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.
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ā
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.
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 " . 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
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.
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.
" . A few of those might start to get the message across.