I am starting to feel similar issues in our environment. I want to delegate more trust to people to help make design decisions about how we use the site, but the powers needed fall somewhere between moderator and admin.
Some examples of things I’d like to enable others to do, without giving them the keys to everything:
View site settings that do not contain credentials to other sites (auth keys, etc)
Create reports from existing data explorer queries
Create/edit groups
Create categories
Edit category settings
What’s the best way to approach this class of problems?
Is the lowest friction way to do these sort of things by considering them case-by-case and adding site settings that enable moderators to do more? Or is there some other design guideline that the team is thinking about with regards to permissions?
AFAIK, much of security in Discourse is an ADDITIVE system. There is no subtract.
Therefore, permissions are only added layer upon layer. A higher-level permission automatically assumes being granted everything in lower permissions. Therefore, it is usually very difficult to find ways to grant a single high-level permission to a user without granting him/her all the lower permission as well.
And many permissions come in groups, meaning that they are granted (or not granted) as a single unit.
In other words, don’t think of Discourse as a database’s GRANT command. It doesn’t work that way.
I have found that, in order to have fine-grained control, you usually have to create a LOT of user Groups, which are permutations of simpler user Groups. This way you have more control over the access aspects of things; the downside is, of course, lots of lots of groups, plus each category’s Security tab is very very long.
As for permissions granted as a single unit, you’re out of luck. There is no way to just pick one permission and deny others.
So maybe that is the path-of-least-resistance way to add features like these, which is the angle taken in the topic I quoted in the OP, which advocates for a similar feature that would allow moderators to create groups.
I’m wondering if the team feels like that’s the best way to approach adding features like these in the future, or if they have something else in mind.
But moderators may have too much power, more than you’re willing to give usually. That’s usually what happens in an enterprise install where you need info compartmentized.
I had this when working with Discourse in a big enterprise.
The solution there was to have a very responsive admin team, that could handle flags and PMs (asking for categories, groups, etc) ASAP.
And it works well, because on enterprise people are really used to ask a department to do anything they need (need water? ask supplies dept, need a new chair? ask predial infrastructure dept, need a category? ask discourse dept.).
Very open to having this discussion but we don’t currently have anything in the pipeline as far as opening up these permissions go.
I can see the merit of some of those requirements for all sites (e.g. running pre-defined data explorer queries) but I’d be concerned about widespread access to creating categories given the issues that category bloat can cause.
For me, Admins and Moderators have fairly distinct roles even though there can be some overlap.
I think it would be a poor idea to give non-Admins the ability to create categories or otherwise restructure a forum. On the other hand, I think it would be good for non-Admins to make suggestions. eg. “I notice the tag pr_welcome has been used a lot. Do you think having this be its own category would be a good thing?” or “The Releases category doesn’t have many topics, might this be better as a tag?”
Regarding database queries, I have often thought it would nice if Reports were further developed. If not to where custom queries could be entered, to where an Admin could add vetted queries as options.
This could be a very interesting addition to the upcoming moderator dashboard. @HAWK@eviltrout - thoughts on adding a checkbox to data explorer to display the query on the dashboard?
Exactly right @fefrei. Admins should still be able to create and save queries that moderators can’t see. The checkbox will determine whether moderators can run the query via the dashboard.
If checked, moderators will see the query title and description. I don’t think they need to see the full query.
In our case, the issue is that there are really separate roles for “(re)structuring the forum” and “administering the forum”.
The latter is an IT person, who wants to make sure the site is up and operational, that backups are taken when necessary, and may need to have access to credentials for integrations with other sites. But they are doing this type of work for many systems. They aren’t really interested in thinking deeply about how to build a community, encourage civilized discourse, or work with people across the organization to develop patterns for communicating and sharing knowledge.
The former are people like me, and other official and unofficial leaders and community builders. We spend time thinking about how to encourage people to collaborate, when it’s appropriate to use slack vs. email vs. discourse vs. google docs. We help nudge people across this sea of tools to use them more effectively. But we shouldn’t all necessarily have credentials for our organization-wide authentication system or access to other people’s PMs, or the ability to download the entire database.
The way things are currently designed leaves us in a situation where we are not able to empower as many people as we’d like in the former activities, and/or we may burden the IT folks with things they don’t understand or care about too much.
It’s not a dire situation or anything, but there’s plenty room for improvement.
I was thinking that it’s not that big a deal to assign you as an administrator, but this is a good point. The IT guy doesn’t care what the categories are and you shouldn’t have access to everything.
I think a plugin that hides those options from the UI is probably the solution. If the IT person needed to change they could disable the plugin by removing it or make changes from the rails console. It shouldn’t be a difficult plugin to write.
this idea!