Now that we can grant specific groups access to whispers, we are very close to being able to remove moderator access for most of our internal users.
And, when we started to remove access, we realized we are missing one final piece and had to revert the change. We make heavy use of assignments (to users and groups) in our organization.
All of this is “hidden” from our community of users. This really works for us, because sometimes we assign threads to a group because…
we’re just passing along feedback (an FYI)
we need an action taken
we don’t know if some action needs to be taken (and the group will figure it out once they see it)
Internal users are trusted to assign threads to other groups in the organization.
What we realized, as we began to revoke moderator access, is that group visibility and the ability to assign to groups can only be opened as far as “only group members, moderators, and admins” before we’d have to allow non-internal users the ability to see an assign to groups.
It would be great if these permissions could be defined at a group level as well. For us, this is the final missing piece.
What’s driving us:
I think it’s important to mention why we’re on this journey at all.
We have ~170 moderators on our instance. These users don’t need access to the e-mail addresses and IP addresses of our users. Especially as our organization keeps growing, it feels risky to have this information available to everyone.
To be honest, I had no idea that option existed – and actually, it’s turned off on our instance! I impersonated another moderator on our instance and indeed, they can’t view e-mail addresses.
I swear I had access to see e-mails back when I was “only” a moderator (not an admin) – maybe we had a different setting back then (our instance has gone through quite a journey in the last 8 months).
Thanks a lot for pointing that out.
So that definitely removes some urgency – and generally I would still like to see the platform keep moving towards flexible group-based permissions rather than these more rigid options.
We are also working through a similar issue at Discourse, in fact I do not have admin/modertor access on our dev instance. I completely hear you on the vast advantages of keeping the admin/moderator count low.
Can you spell out the problem?
Keeping in mind there are a few building blocks you can lean on:
Category moderation, you can define moderation over specific categories to specific groups. This allows high trust users higher flexiblity.
Trust level system … at TL4 (manual) a ton unlocks
assign allowed on groups site setting (which unlocks assign for specific groups)
We have a bunch of different teams at our company who contribute to our Community as SMEs for whatever piece of our product they’re responsible for. A group is created for each team, and when a team’s expertise is required in a topic, the topic is assigned to the team (and usually then assigned to an individual, who unassigns it from themselves when they’ve contributed all they can)
We don’t want to reveal to our users how this is all working. We try and keep expectations low (it’s free support we’re offering our open source users), we don’t want users to start asking “Why can’t you just assign this to the _____ team already??” – in fact, we don’t want our users to know these groups exist at all.
Usually, I’m all for radical transparency… but this works really well for us.
And, we want our internal users to be able to see all of these groups, the topics assigned to them, and have the ability to reassign to other groups.
This means that if we want to make sure all our internal users can see / interact with the groups the way we need them to, we have to grant at least moderator access. This isn’t ideal.
I hope this helps clarify the problem. Let me know if I can clarify anything further.
In fact this would probably simplify the UI and internal implementation that would no longer have to reason about enums and so on.
The hardest thing about a port is that “group owners” is not a real group, so we would need some sort of new primitive to describe what it means. Group id is not enough.
Honestly, I’m having a hard time thinking of a real use-case where group owners shouldn’t be allowed to do all the things by virtue of them being group owners.
In which case you could maybe ignore that problem and grant group owners god-rights. The rest of the permissions then being delegated to individual groups.
I hear you, but I worry a lot about making breaking changes. By supporting a simple “group owner” shadow group we can completely port to a new UI without breaking anything for existing users of the feature.
