Category-Specific Moderators, phase 1 RFC

Feature
1

Preliminary spec for this feature.

Overview

Moderator authority may optionally be assigned for a particular category and its subcategories rather than over the entire site.

  • This feature does not replace the existing whole-site moderator role.
  • This feature does not alter the site-global access privileges associated with Trust Levels.
  • The definition of “staff” (admin or global moderator) does not change with this feature. Category moderators are not considered to be staff.

A moderated category is not necessarily a private category. Restricting general access to the category remains an admin function using the current category security controls.

There can be multiple moderators for a category.

Authority

A category moderator will have authority to do the following, always restricted to the categories that they moderate:

  • create sub-categories within the categories
  • delete, edit, wikify posts in the categories
  • delete, close, auto-close, reopen, archive, unlist/list topics in the categories
  • pin topic (category-scope pin, not global)
  • Change Category settings: color, name, description, security, auto-close time, images, badges-enabled.
    • Do NOT allow to change: Email-in address, Fixed position.
  • Change title and category for a topic, as long as they moderate both source and destination (NB: TL3 permissions will let them move topics anywhere)
  • change category name
  • restrict sub-category access
  • invite new members with access to the category (this does not override the the must_approve_users site setting)
  • view/export list of users who can post in that category? or are members of any group with write permission for that category? (should not include admin, site moderator, TL4s)

Category moderators will not have authority to:

  • pin topics globally
  • banner topics
  • move a topic to any category they do not moderate (unless also TL3)
  • impersonate users

Category Moderator authority can also be assigned or removed by an admin or full site moderator. No automatic revocation of authority.

Appointment or dismissal of category moderators will be a Staff function.

No changes to the standard authority structure for other (non-moderator) users to carry out actions in a moderated category.

UI Implications

UI switches that check if the user is a staff member will have to be reworked, as access to some moderation features can be had without being a full-site moderator.

No special badge for category moderators. Posts by category moderators will not be distinguished in any way from posts by other users.

Category Edit dialog

  • category moderator can see and use the Edit button & dialog on the Category page
  • on the Security tab (edit_category_security.hbs), add list of moderators beneath the current Permissions section; staff only can appoint or dismiss moderators here
  • for the “email in” and “fixed positions” settings in the Category Edit dialog, change the text (for category moderators) to indicate that this is an admin-only feature, with no links to the inaccessible /admin pages.

Need UI for…

  • create sub-category under moderated category (available to category moderators)

API Changes

  • add list of category moderators to JSON representation of a category
  • category#update options: add moderator appointment & dismissal

Implementation Notes

We already have a CategoryUser class. Add a moderator flag to that. But do not interfere with any existing notification_level setting. Default notification level for a newly-assigned moderator should be the maximum value.

Extend the existing Guardian functionality to cover moderator powers. Try to avoid making a new thing for this.

For the items listed above that relate to permissions and invites:

  1. every moderated category will have one associated group (generate a name for it from the category name?)
  2. these special category groups should not be visible to anyone besides that category moderator
  3. category moderator does not have authority to create additional groups
  4. category moderator may only change permissions for any sub-category, as follows: remove “everyone” access; add access for the category group (per 1. above).
  5. category moderators should not be able to fiddle with permissions for any of the other automatic groups (admins etc.)
  6. category moderator can use the Invite button at the bottom of any topic: such invites will include access to the category group.
  7. category moderator can use the Invite function to invite existing members into the category group, not just unregistered users.

TBD

Can moderator create additional groups within the category? i.e. subcategories with different group permissions.

Perhaps category-specific Trust Levels could be defined. Not in phase 1.

https://meta.discourse.org/t/what-do-user-trust-levels-do/4924/6

Feature discussion is at https://meta.discourse.org/t/category-specific-moderators/11668/99

25 Likes
3

out of scope for v1 and probably no.

out of scope

disagree

no

4

These three look like they could turn into an… interesting… snakepit. I wonder if it might be better to:

  • Category Moderators appointed/dismissed by Staff only
  • Category Moderator may deputize/bless members. (Essentially, bump user to TL4 equivalent within category + some ability to handle flags)
5

@Sailsman can you give an example of what worries you here?

I’m trying to avoid creating any new types of access authority besides the single “category moderator” power. So the initial moderator for a top-level category must be appointed by Staff, but then the moderator can appoint others within that category. By “deputize” you are suggesting a lower level of authority, but I don’t want to have levels of moderator authority if that can be avoided.

6

I agree with @sam on all these items. Will update spec.

Re the TL3 privileges, I had not realized how much customization was possible for trust levels. I think those settings ought to be able to cover this.

7

I hear what you are saying regarding simplicity.

My main concern is this:

  • @UserA is appointed moderator for OurCrazyCategory.
  • @UserA appoints @UserB.
  • @UserB can now dismiss @UserA? Whaat?!?

I do note that you have removed that last option, so some of my first thought is now moot…

I just suspect that allowing someone to moderate a small section of your site, and allowing that person to decide who else can moderate are two very different things. A category moderator should certainly feel free to nominate people he has interacted with, but the final decision should be left to staff, who may have a much broader look at a user’s history and habits. This is especially true in a community large enough to need category moderators.

1 Like
8

In my use case it does generally make sense for a category moderator to be able to appoint or dismiss others.

But I’ve realized that that’s just in my case & that rule shouldn’t be imposed unilaterally. So I agree with you, and will alter the spec to state that appointment & dismissal of category moderators should be admin function. For my particular case I can always build a custom UI.

9

On the same reasoning as my response to @Sailsman63 above (me thinking too much about my own use case rather than what’s appropriate for a global feature in Discourse), I’m bumping some other features to phase 2 (or later).

Specifically, anything to do with flags, blocking users, and viewing logs. All those things can remain as they are handled currently (admin functions) without any special category-moderator treatment. I expect that eventually category moderators should be able to do some of this stuff but propose that we let the feature simmer first before giving any further authorities. Let the category moderators mess around with posts, topics & sub-categories first and then see how it works out.

10

@sam What is the process for getting this ratified? Anything missing from the spec?

11

This is not on our roadmap through 1.3.

12

@codinghorror Understood. I’m proposing to do most or all of this work myself. I’m just hoping to get some verification that there’s nothing here that is going to conflict dangerously with other parts of Discourse. The longer I maintain a separate fork the further it can stray from core.

1 Like
13

Can’t this be made as a plugin?

14

@erlend_sh I think that, as specified, this feature has go into core. For example, there are changes to the database and to the permission checks for various capabilities.

But I don’t understand the plugin system very well. Is there documentation that explains clearly what’s possible?

15

Impossible, this needs to go in core, its a core feature.

16

I discussed this with @codinghorror and we would like to hold off this work before some other work happens.

In particular group management needs a serious iteration first because it is required for this work AND blocking lots of people.

@lightyear started some work on Improved Group Members Management but it is not fully done. There is no easy way to manage a group with more than 200 users the UI does not scale.

Additionally we really want the concept of “group owner” first, which basically gives a normal user the ability to add and remove users to a group they own.

We need the above properly specified before working on the full blown “category moderators”.

4 Likes
17

I moved all the group-related stuff to a later phase, there seemed to be too many ways that categories & groups could get tangled and I’m trying to follow your general philosophy of keeping feature units as small as possible.

I’ll have a PR ready tomorrow so you can look at it at your convenience & decide if I’m on the right track and following Discourse coding conventions. I can pitch in with the groups stuff as well if help is needed there.

1 Like
18

I had a look at the PR and it is on track for the spec above. However I do not want to move ahead with any of this before we get group management fixed.

Building this without having a solid group management UI and process is just like building on quicksand. We can not allow it.

19

Sure. I will apply your PR feedback and continue keeping this warm for later.

20

@sam can you clarify what are the pressing issues with the existing group management? Is it purely a UI concern? I think you are suggesting that you would like something better on the group admin page for viewing & maintaining large numbers of users.

For “group ownership”, I’m trying to understanding how this differs from the category-moderator idea. Does it make sense for someone to be able to administer group membership without being able to administer settings for any category/ies that group is associate with?

21

This feature request seems relevant.