Permission Changes (moderators have less)

(Sam Saffron) #1

Moderators have been demoted in Discourse.

Back in May I demoted moderators a bit Moderator Permission Set , this has not been enough.

Some Discourse communities seem to need the ability to “fend off” certain discussions from moderators. For example: “Should we fire Sam?” discussion may only be visible to staff? that are in the HR group.

This change is quite wide, the following changes were made

  • Moderators follow the same visibility path from topics as regular users. A moderator will have to be in a group with “see” permissions to see discussion in a group.
  • Moderators can only handle flags in categories they can see
  • Moderators can not snoop through user’s PMs
  • Moderators can not see topics they have no visibility to in user’s profiles

Nothing changed when it comes to admins.

We believe this is a safer and more secure default.

Restrict moderators from reading all PMs
Remove moderator ability to view users email addresses
What permissions can admins give moderators?
What are the 'Private spaces'? What difference with 'Categories'?
(Kane York) #3

Just a note: moderators is indeed a group that can be addressed in permissions, so you can add their category permissions back if you so desire.

(probus) #4

What is the reason that moderators need to see users email addresses?

(cpradio) #5

I can think of many reasons, identifying multiple accounts/similar accounts, bot accounts, etc. Managing a site that used to have 5000 bot registrations a day, seeing the email address helped me knock out a ton of accounts quickly.

(Rikki Tooley) #6

Why should admins be able to?

(Lee_Ars) #7

See this topic for a discussion on this issue.

(Lee_Ars) #8

FWIW, I promoted my two site moderators to Admin some time back so that they could assign users to groups. The default moderator permission set didn’t appear to allow it and it’s functionality I need, since I have mods precisely so that I don’t have to be bothered with stuff like group membership.

I’d prefer a method to allow moderators the ability to do everything except change system functions. It sounds like rather than globally limiting moderator powers, what we need here is the concept of topic-level moderators versus global moderators. Topic-level mods would have the reduced level of permissions you’ve set forth and would be explicitly constrained to one or more topics; global moderators would be less limited.

With the current mod permission set, I’ll have to leave my mods as admins for them to do me any good. Which isn’t terrible—they’ve been doing the job for years and I trust them—but it feels less than optimal.

(Sam Saffron) #9

I don’t mind extending with an in-between user (what the old moderator was)

So we have

Global Moderator

The key thing is that we need the new restricted moderator role otherwise there are certain communities that just can not use us.

(Kane York) #10

Maybe you should, as part of this, consolidate the two (soon 3) roles into a single database field.

0 - Regular user
1 - Moderator
2 - GMod
3 - Admin
4 - Developer (DISCOURSE_DEVELOPER_EMAILS setting - allowed to impersonate the system user)

Actually, maybe the developer level should remain a code-only promotion (I.e. not saved to the db) as it is currently. Just wanted to remind you that it existed.

(Lee_Ars) #11

That makes sense, sure. It goes the other way, too—a too-limited moderator role (not just in topic visibility but also in function) just means that some communities will give up and promote mods to admins. That has its own undesirable consequences. I trust my guys, but that won’t be the case everywhere; if a community needs moderators to be able to perform some tasks that are currently admin-only (I keep coming back to group management, but iirc there are a few others, too), then it becomes a choice of giving a moderator all access to everything—including the ability to take the site offline by changing core parameters—or putting an unwanted burden on the admin.

Having global mods vs topic mods is one way through the issue, but another would be to granularize your permission structure and allow admins to assign abilities to groups or users—sort of like a Windows-style ACL/ACE structure. So, like, “Can read PMs” is a flag that can be toggled on or off for a group. “Can see all topics” could be a toggle. “Can ban users” or “Can create groups” or “Can assign members to groups” could be toggles.

I don’t know how much rework this might involve, but modularizing and granularizing permissions would provide max flexibility while at the same time allowing you to keep less-permissive-by-default moderator roles (you just preconfigure the “moderator” group to how you want the out of the box behavior to be).

(Jeff Atwood) #12

Eh, I want to resist complex permission schemes. Nobody really understands Windows ACLs, even developers don’t understand them.

So simpler is better.

The main reason to demote moderators is so that the defaults become a bit safer. I would rather have one superuser/admin who installed the forum and most requests going through that person.

(Lee_Ars) #13

Profoundly disagree—but will agree to leave it at that :smiley:

It’s not the answer I’d prefer, but there you go. I don’t think ultimately that it will scale very well and that the option to at least invest group management should be delegatable. But, hey, I can live with the workaround.

(Josh Brodie) #14

I’ve just installed a fresh instance of discourse and find on promoting a new user to moderator, while they cannot access forum settings, they can view my API Keys (id/secret) in the staff action logs. Is this information a moderator should have?

(Sam Saffron) #15

That is absolutely a bug

(Josh Brodie) #16

Would be nice to know whether anyone can reproduce. I’ll get screenshots sorted ASAP and submit an issue unless there’s any objection.

(Rikki Tooley) #17

The Windows permission system is confusing yeah. But this is something phpBB very nearly got right. There must be a way of adding flexibility whilst making it easy to understand…

(Sam Saffron) #18

One second here, what flexibility exactly is missing here? Can you detail it?

(Dean Taylor) #19

This video about WordPress permissions is an interesting developer focused walk-though of the complex yet powerful system WordPress has for user permissions.

Yes indeed WordPress permissions may be over-the-top, but I leave this here for reference purposes.

There might be some use cases created / found by watching this video, which may reduce any re-engineering work required by later changes to the Discourse permissions system.

(sparr) #20

Would you call Drupal’s role/permission scheme complex? I never had trouble understanding it.

(Jeff Atwood) #21

I have never heard anyone say anything positive about Drupal. You might be the first.