Yesterday, @codinghorror announced a new feature to try and curb behavior that can cause performance issues (see Using private / personal messages as long term chat). After a bit of discussion, @sam and I had a conversation about PMs vs private categories, and I learned that other than visibility, they are not very different. Other than their visibility, particularly with group PMs now being first class citizens, the biggest difference is who can create them. At the moment, with default settings anyone can create a PM to a xx people, but only admins can create groups, and thus private categories.
Allow moderators to create groups
The main feature request is to allow moderators to create groups, in a similar manner to how they create categories.
Necessary changes
New site setting allow moderators to create groups
Allow moderators to see the groups page in the Admin interface
Allow moderators to create groups, assign group owners, members, and change all other group settings
Potential Issues
How to continue to allow Admins to create groups that are not visible to Moderators?
Proposed Solution
It is currently possible for a moderator to create a new category they cannot see after creation (by assigning it to be viewable only to Admins. Whether this is a bug or not is an issue for another time. I would propose a similar solution for group creation. Create a single check box (ideally viewable only by Admins) that says Do not make group visible to moderators. This option would only appear if the allow moderators to create groups is enabled, and would allow for admin only groups to still be created. If this box is checked, then these groups do not appear for moderators in the groups interface, just like categories are not shown to those users without proper permissions on the /categories page.
I am not really following how this relates to the other topic at all. There are built in categories for Staff in every Discourse. If you are a moderator you already have access to this category, and only staff can read/post there.
I do not understand this request. Can you explain the need with specific, real world, actual examples?
Right now reading what you wrote I am super confused. Forget the “feature”, explain the need. Use real examples. What is the goal?
Sorry @codinghorror, let me try and explain the need/goal here a bit better.
Right now, if group of users on the Discourse want to have a discussion without doing so publicly there only option is to do so in a PM. In the other topic, you brought up concern that long PMs have negative performance implications. If a small group of users wants to have a discussion, and creates a PM to do so, they will keep discussing in that PM, without thinking of creating a new one. Without groups, that is their only option without using another piece of software.
Here are some specific, real world, actual examples:
Using the PM @sam brought up, 3 users started talking about an idea to put more hair models in the game. Then the discussion turned into lets make a mod for all these models. Discussion went on (as @sam pointed out) for a long time. If moderators were able to create groups, 8bitcrab could have made a group for the 3 of them when he realized the discussion would continue for a long time, and created a category for them to go into detail on their ideas.
Expanding example 1: Stonehearth as a game is very mod friendly. Certain users are very involved in making mods for the game, while other are more one-off developers. Some of the “busier” developers have expressed interest in being able to discuss ideas, share mods, etc. with this smaller group before sharing them publicly with the entire site. Right now this is not possible without using PMs, but grouping these users and creating a space for them to do so would be ideal.
Different type of example here. Different style of Discourse staff organization. Here on Meta, all of the developers are admins, and they are also the moderator team. The goal here on Meta is the development of Discourse, and thus the admins/mods want to be here as much as possible. On other sites, the admins might be the owners of the “thing” the site is about (the game, the company, the product, etc.), and have other primary tasks in their day-to-day. Take Stonehearth: the admins on the site are the games developers. Their primary interest is developing the game. They visit the Discourse daily, but not with Discourse management in mind, but game development (view bugs, check feature requests, troubleshoot crashes, etc.). They’ve selected a group of volunteers (the moderators) to help run the day-to-day operation of the site. This team does not have the need (nor want) for access to things like site settings or master API keys, but group creation is a useful tool for this type of management style.
Final example. This is not my idea, I saw it here on the Discourse previously, but it is a good one I think fits. A group of users on a site are planning something in real life. They are trying to organize this group on the Discourse. There isn’t anything secretive about this group, so the discussion is happening in a public category. The organizer of this trip wants to mention all the people going, but there are 15 and the limit is 10. He contacts a moderator who finds there is nothing she can do to help. She is unable to raise the limit (site setting), and cannot create a group that is mentionable by the group, because both require an Admin.
To summarize, there are lots of real world examples for why this could be helpful. I think part of where I am going with this is that is should be possible to run a Discourse site, and take advantage of all of its features without an active Admin. Once a site is set up, and settings are configured, an Admin should not be needed on a day-to-day basis. From my limited knowledge of what an Admin can do (just spun up a dev instance yesterday), outside of initial site configuration (settings, email, badges, and API), groups seem to be the only setting they have that could reasonably expected to change on a more frequent basis.
Sounds to me like the real problem is you need an Admin that is an Admin in more than name alone.
For example, if I felt there was a need for a SitePoint Group and Category here I would petition for a group and category to be created.
I would not ask for Admin abilities.
There is nothing saying that an “owner” can’t delegate Admin privs to a “non-owner” if they can’t or don’t want to be bothered with performing Admin tasks.
But making ability subsets sounds like a fall back to the vBulletin role settings hell.
The difference (at least on Stonehearth) is that moderators can create categories, as that is a site setting that is enabled. As groups have become more powerful with all the changes in A15, it feels strange that a moderator can create a category (very visible change) but not a group (much subtler).
No there isn’t, but the admin role has the ability to change things that are much more important than groups. An admin can change how login works, change the site name and logos, and all sorts of other “important” features that they shouldn’t need to see to create a group.
I do not want to see anything like the monstrosity that is vBulletin role settings. I guess what I am looking for is a better separation of permissions for Admin & Moderators, given the current feature set. I could be wrong (please correct me if I am), but there have been many new features added over the development of 1.5, and Admin/Moderator permissions have not changed. As I said above, I don’t feel it should be necessary to have an Admin close by to run the day-by-day of a site. I don’t want to be an Admin, I just want to have access to an expanded feature that is much more powerful than it used to be.
Why don’t you just have more, or more available, admins? I agree with @Mittineague here this sounds a lot like “we don’t have enough admins, and/or our admins are too busy to help”
We do have available Admins. If we need to do something “adminy”, we can ask and it will get done. I just don’t feel that creating a group should require an Admin.
Let me ask this: Why is there a site setting to allow Moderators to create categories (even allowing them to create categories they can’t see after creation), but you are very opposed to a site setting to allow Moderators to create groups?
I am having a very hard time understanding why there is a distinction between the two! What makes groups so special that they require an Admin’s involvement?
Edit: So, I thought about this more as the day went on. I looked into the current #faq on the various user state in Discourse, and found the following.
Admin
Admin users are the superusers in the system, they can:
Impersonate non admins
Change site settings
Create groups
Amend site customizations
Perform all the actions moderators can perform
Read any personal message
Moderator
Power user capable of moderating the site:
Gets shield icon next to name on posts
Can perform all actions Staff can perform
Staff
A user that is either an admin a moderator or both.
Immune to rate limits
Can process flags
Can delete topics and posts, split topics, merge topics, hide topics and so on.
Can view user info including email address
Going through the list of Admin only privileges, I looked to see what each of the items was, and how powerful/dangerous it was, particularly with day-to-day moderation in mind:
Impersonate non admins
I cannot think of a valid reason a moderator would need to do this frequently. Impersonation would be useful if a user is reporting an issue that you cannot repro as staff, but a moderator could just as easily create a sock account to look into this.
Change site settings
Site settings shouldn’t be changing on a regular basis, and thus moderators should not need access.
Create groups
This is the odd one to me. It seems similar to create categories, which is an existing site setting to allow moderators, and depending on the site could be something that is used frequently.
Amend site customizations
Similar to site settings, these shouldn’t be changing on a regular basis.
Perform all the actions moderators can perform
Not-relevant to this discussion, moderators already can do what moderators do.
Read any personal message
This is in-between for me. I cannot see a reason why a moderator willy-nilly would be reading PMs, but there are some cases (like a flagged PM) where this could be necessary for a moderator.
So, going back to codinghorror’s question, looking at the list of Admin only rights, almost all of their rights should not be needed on a regular basis, on 90+% of the forums out there. Groups just seem like an outlier in their list of rights as something that could reasonably be used more frequently. If the admins so desire, a moderator should be able to create groups without also having permissions to modify site settings, view all PMs, impersonate users, etc.
Not sure, that was @sam’s call. In general categories should not be something you are changing all the time in my opinion. Categories are like the News, Business, Sports section of a newspaper… if you are changing that a lot it is a bad sign.
I share that opinion. Categories shouldn’t (and we don’t) change on a regular basis. However, they likely do change on a much more regular basis than a typical site setting would, or a site customization, and are more part of the organization of a site than the administration.
I am glad to hear that! Please let me know if there is more info and/or goals/needs for this feature you would like from me.
Any update on progress here? I just wanted to ensure this is still on your to-do list (it could be way at the bottom ) as it isn’t listed in releases, nor does it have a planned tag.
I think the focus at the moment is on improving the groups page and groups admin UI – and most significantly, letting people request membership in the group to self-serve.
We have a big requirement to have someone that can just admin the groups and categories but not have full admin rights so this would very welcome. Would love to be able to utilise the api and build something to assist with this however wouldn’t know where start either.
@codinghorror asked me to post an update here. Short version: I still think we should add a site setting allowing moderators to create groups.
Longer version:
Since I first wrote this (wow! over two years ago) groups have evolved quite a bit. Groups have been moved out of the admin section and now exist solely in /groups (perhaps this doing this securely less technically tricky?). Groups can be freely joined by users, or they can support “join requests”. The concept of “Group Owner” allows non-staff users to manage membership of a group, as well as group settings like name, description, avatar flair, and interaction. I’ve also seen first hand how groups can be used to manage incoming emails (like we do here at Discourse).
My original thought still stands - you shouldn’t need to be an admin to create a group. I recognize that some sites wouldn’t want moderators to have access to this, so I believe a site setting makes sense. Being an admin gives users significant control over the site, including downloading a complete backup, changing themes, and even changing site settings like login. You should be able to create a group without gaining access to all those abilities.
@jomaxro stuff gets very complicated since we allow moderators to be excluded from certain groups. I guess we could allow them, by default, to create groups that they moderate. But then are we setting ourselves up for a problem when they remove themselves from group owners?
We already allow moderators to create categories they cannot access (I just tested this to be certain on try). Not sure how groups are any different. Groups have 4 visibility options: Everyone, Group owners, members and admins, Group owners and staff, and Group owners and admins. There are two ways I can see things working here:
Automatically make mods owners of groups they create if they wouldn’t otherwise have access.
Don’t do anything special (let mods create groups they can’t do anything with after).
Either way, I don’t think we need to protect moderators here. If they decide to edit a group so they can’t see it anymore, they can bother an admin to fix it. I agree there’s a crazy number of edge cases if we try and make this “fool proof”.
) as it isn’t listed in 