Draft specification: more granular community permissions

[kaberett]

This outline is based on previous discussion about how this might work. Currently the best option seems to be a pretty unwieldy matrix: if you've got further suggestions please do let me know. Because it's unwieldy, the rest of this is going under a cut.

THE CURRENT SITUATION

Community permissions are scattered over a number of pages and offer a limited set of options. To here summarise the current situation:

Under ?authas=comm: Profile, Style, Settings, Tags, Tracking

Settings

Membership is: open/moderated/by invitation only
Posting access: anyone (even non-members)/all members/select members
Entry moderation: [ ] All entries must be approved by a moderator before they will be posted to the community.

Tags
Who can create new tags, add tags to entries, and remove tags from entries? Anyone/Members only/Administrators only
Who can add existing tags to entries? Anyone/Members only/Administrators only/Entry author and administrators

Edit Community Members

Community members page
select all  [ ] Member  [ ] Posting Access  [ ] Administrator
username1   [x] Member  [x] Posting Access  [ ] Administrator 
username2   [x] Member  [ ] Posting Access  [ ] Administrator
username3   [x] Member  [x] Posting Access  [x] Administrator
username4   [x] Member  [x] Posting Access  [ ] Administrator

PROPOSED CHANGES

Move all permissions governing how user accounts can interact with the community to the Edit Community Members page. Tweak the Edit Community Members page in two respects:

1. instead of a single row of master tickies as the headline, introduce separate master tickies for members and non-members (support request); and
2. move all permissions governing how user accounts can interact with the community to a new Additional Privs page.

The Edit Community Members page checkbox matrix would then look something like this:

                Member      Posting Access      Moderated       Additional Privs
NON-MEMBERS [-] Member  [ ] Posting Access  [ ] Moderated   [ ] Additional Privs
MEMBERS     [x] Member  [ ] Posting Access  [ ] Moderated   [ ] Additional Privs
username1   [ ] Member  [ ] Posting Access  [ ] Moderated   [ ] Additional Privs
username2   [ ] Member  [ ] Posting Access  [ ] Moderated   [ ] Additional Privs
username3   [ ] Member  [ ] Posting Access  [ ] Moderated   [ ] Additional Privs
username4   [ ] Member  [ ] Posting Access  [ ] Moderated   [ ] Additional Privs

Note that it is not possible to make all non-members members of the community (!); I suppose you might want the "remove all members" ticky, so that should be checked by default (rather than greyed out/unavailable as for non-members). The "Additional Privs" checkbox does not autofill anything on the Additional Privileges page; it merely means that the username(s) in question show up there.


The Additional Privileges page would also be a matrix of checkboxes, again with NON-MEMBERS and MEMBERS as the first two rows, with MEMBERS acting as a master influencing all username rows.

The privileges for which checkboxes should exist are (taken from the Community Maintainers wiki page):

... with a matrix where the tickies are:
[ ] ADMINISTRATOR (master ticky, selects all)
[ ] MODERATOR (master ticky, selects appropriate subset)
[ ] add tags to community list
[ ] delete tags from community list
[ ] add tags to community entry
[ ] remove tags from community entry
[ ] edit community style
[ ] edit community memories
[ ] can change comm settings at /manage/settings/?authas=comm
[ ] can change the settings at /manage/profile/
[ ] can un/screen comments
[ ] can un/freeze comments
[ ] can delete comments
[ ] can un/ban users
[ ] can report spammers
[ ] can add/remove posting access to community
[ ] can remove community membership
[ ] can invite people to the community
[ ] can approve requests to join the community
[ ] can manage the moderation queue
[ ] can edit, delete, or flag posts made to the community
[ ] can upload userpics for the community
[ ] can wear the mod hat
[ ] can access community's recent_comments.bml page
[ ] can add other owners
[ ] can remove other owners
[ ] can add people to groups on Manage Community Members
[ ] can remove people from groups on Manage Community Members
[ ] can add people to groups on Additional Privs page
[ ] can remove people from groups on Additional Privs page

Points for discussion

1. This is going to be enormous. Suggestions for how to minimise scrolling?
   
2. It is possible to duplicate settings between the various pages mentioned in section 1 and the proposed new privs management interface; however, I suggest that's prone to error and confusion and might therefore be better off not happening.
   
3. I'm not convinced that we actually want the last two tickies on my big list there; I'm not convinced there's any point in letting people who aren't administrators have the ability to grant and revoke administrator status :-p
   
4. Are there privileges missing off that list that you can think of? Are there points you think should be subdivided? (I am thinking particularly of edit/delete/flag posts made to the community, and un/screening comments: I can see a scenario in which you want people to be able to screen comments until someone with more seniority comes along and drafts a response and only then unscreens it, to minimise flamewars; ditto un/freezing.
   
5. Terminology: "Additional Privs" is a placeholder; suggestions for something clearer/more user-friendly enthusiastically welcomed.

Comments

[zaluzianskya]

It seems that the point of this overhaul is to make the whole thing more granular, so that, for example, communities can have people who can maintain the tags or edit the style without making them admins. Presumably, only trusted users would be granted these privileges.

[neighfeni]

My apologies, I was mostly talking about point 3: "I'm not convinced there's any point in letting people who aren't administrators have the ability to grant and revoke administrator status".

I thought you could make it where they can maintain tags without being a mod. Or am I thinking of adding them to current entries?

[zaluzianskya]

You are.

It's currently possible to allow all members to create new tags, but not to limit it to a select few members (if I recall correctly) or to allow anyone besides admins to delete tags.

[kaberett]

So to show my own motivators here: I'm currently allowed to add tags to entries in dw_suggestions but there's no way to let me, specifically, remove tags from entries without granting me admin status. This is non-optimal.

As you mention upthread, it would also be good for communities that have e.g. "style admins" to be able to grant someone the power to tweak styles and layout-related code without also granting them Absolute Cosmic Power over all members when it's irrelevant to their role, then trusting them not to use it.

(Sorry if this is unclear; on my way to bed and will give in-depth replies to everything tomorrow!)

[kaberett]

Yes, thanks for the input: I included it from the wiki list for completeness (I would otherwise have had an itch of "but we haven't discussed it!") but I think I'm in agreement that it would be much too easy to tick accidentally and doesn't make any sense as an option.