dw_dev | Draft specification: more granular community permissions

Entry tags:

speccing

Draft specification: more granular community permissions

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:

instead of a single row of master tickies as the headline, introduce separate master tickies for members and non-members (support request); and
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

This is going to be enormous. Suggestions for how to minimise scrolling?
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.
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
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.
Terminology: "Additional Privs" is a placeholder; suggestions for something clearer/more user-friendly enthusiastically welcomed.

Flat | Top-Level Comments Only

My first reaction is an excessively nitpicky visual/spatial thing, in that I would want some small but noticeable separation for non-members, but I think the top placement works well.

Absolutely agreed! Suggestions welcome. Additional h-rules under title bar/non-members/members? oooo or how about

----------
MEMBERS (dark gray background as visual highlight?)
username1
username2
...
usernameX
----------
NON-MEMBERS (background of some type?)
----------

I think the top is the right place because there is only one of it, and there iirc up to 100 members per page.

Also maybe repeat the non-members thing on every page? idk which would make more sense.

Yeah, okay, good shout.

If members/non-members are going to be master rows, I think they should appear on every page so it's clear what's going on.

Something like:

                      h2 Community Permissions 
[h3 header] Member     Posting Access     Moderated      
h4 NON-MEMBERS link       [ ] Posting Access [ ] Moderated  

[h3 header] Member     Posting Access     Moderated     Additional Privs 
h4 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

(where the link under member for non-members goes to the place where you control whether they can join or not)

Edited 2015-09-13 10:23 (UTC)

not-quick-but-very-dirty screenshots

Rather than "should we subdivide any of those", I think we can probably compress some of those additional privs so it is less WALL OF OPTIONS:

-- add tags to community list/delete tags from community list
-- add tags to community entry/remove tags from community entry
-- can change comm settings at /manage/settings/?authas=comm/can change the settings at /manage/profile/ (as just "can change comm settings"); maybe also "can change/customize style" belongs in here
-- can un/screen comments/can un/freeze comments/can delete comments/can report spammers/can access community's recent_comments.bml page (as "can manage comments")
-- can remove community membership/can invite people to the community (and possibly a few other consolidations there, I'm not sure)
-- all the "can add"/"can remove" at the bottom should be "can add/remove"

I'd much, much rather do this as broader categories of permissions and only break them down later if people request it.

HA. Yes. That solves the major problem, and having the detailed spec means it'll be easier to break out if it comes to it...

(FYI by default[1] I am intending to give this a week or so for discussion then transfer conclusions to a new GHI, unless you have a different preferred workflow.)

[1] i.e. if there are no changes more significant than the one you proposed here

I still kind of want to see a mockup of the workflow so I can wrap my brain around it, and I'm kind of wondering if it could get simplified further, but ... hrm.

Okay, I'll give it a day or so for people to comment then mock up some screenshots?

\o/ (Sorry, I'm just having trouble turning text tables into actual workflow!)

There really is something nagging me about how it could be simplified further but my brain is refusing to cough it up, probably because I swear I've dropped forty IQ points on the floor in the last year because meds. Sigh.

not-quick-but-very-dirty screenshots

(Also, note to self: this is going to need FAQs ahahahahaha.)

Freeze/screen/delete arms races are great fun! I will always propose logging of various community admin actions, viewable by owner & admins, as a technical umbrella which can be used to support accountability amongst the people who are let to do the thing.

Not an Admin of a game, but as someone who has seen crap and heard of some messed up stuff, THIS. And don't have it where it can be deleted, or where non-admins can change admins and the like. Period. Far too easy for abuse by jerks.

Pardon the character account, my phone browser is refusing to switch accounts.

~lil_rebbitzen

Edited 2015-09-13 21:33 (UTC)

What happens to individual members' tick boxes when I start ticking and un-ticking 'MEMBERS' tick-boxes? Should all member tick-boxes get ticked when I tick them? Should members get granted whatever I specifically gave them plus general member privileges (and next time I open the screen, should this union of privileges be reflected, or should it always happen in the background)? Should MEMBERS just be a template for future members when they are added, and not affect current members at all?

Coming to this as a new user, I would expect the MEMBERS and NON-MEMBERS to automatically fill in all the tickboxes for the appropriate users, there and then, in front of my eyes. IMHO that's the only way for it to be clear and ambiguous what they do.

My expected behaviour with respect to the MEMBERS checkboxes would be exactly as

swaldman describes; this would be consistent with behaviour in other places on the site where master tickies exist.

Please take everything I say with a pinch of salt, as I've never been a community mod and thus never used any of this. re the five points:

1. The additional privs page will be enormous if there are a lot of users with additional privs. Do comms give lots of people these privs? If so, it may be sensible to paginate it? How feasible to provide a search box (for username) at the top? Rah's contractions to reduce the number of columns make sense. I don't see another way to make it smaller without implementing a full-on roles system - which would be much more work and is probably overkill.

2. Please please please no duplicate settings. And yes, all the related settings should be in the same place.

5. "Administrative privs"? Because that's what they are, really. Might cause confusion versus who is named as an admin, though.

1. No, comms don't tend to give lots of people these privs; but yes, I'd expect the new page to inherit pagination from the Edit Community Members page (which splits the list into 100 members per screen).

2. YES QUITE (I am a bit horrified that Posting Access seems to be semi-duplicated currently, and haven't investigated how these settings affect each other when altered...)

5. Yeah, that namespace collision is why I was trying to avoid "Administrative privs" as a descriptor, not least because I'm suggesting folding into that page some thing that haven't historically been considered "administrative", such that there's the additional potential layer of confusion. (I think this sentence got away from me a bit. Please do let me know if it's incomprehensible.)

"Community control" is maybe better than anything involving "admin".

You know, the existing role below admin is moderator, even that only shows up in the grid when you have moderated posting turned on. People who are not familiar with the LJ/DW terminology think that "moderator" includes things like comment freeze/screen/delete, in addition to the DW/LJ "manage moderation queue" power.

What if all these a la carte powers got bundled into "moderation powers"?

Existing moderators should be given only queue moderation by default. Admins could grant additional moderation powers to selected people if they wish. When creating new moderators, they could treat queue moderation as just another power and not The Main Thing.

I know this isn't one of the stated questions exactly, but what about allowing admins to create privilege groups and then assigning members and privileges to them? It would crack the huge matrix problem.

Every community would need a non-empty Admins sort of group with all the privileges and automatic membership in every other group, a Members group which contains all the members and a non-members group which contains the rest of Dreamwidth implicitly. Members could then be added to Admin or some custom group (e.g. a group that can screen comments and approve members or one that can adjust tags) You'd need a couple more privileges:

- Create community privilege group / change privileges
- Add someone to a group you are in (Admins are in everything, so they can seed new groups)

The interface could then be very much like filters, but with a long list of privileges (maybe even grouped, so that an admin could, for example, give a group all tag-related privileges or drill down for specific ones) in addition to the list of users.

This would be nice because it's relatively compact and because once the community admin describes a role, they can just assign users to it rather than click the same tick box pattern for each user doing that job.

(Discussion that's not related to my explicitly stated questions is very very welcome! I included them as a jumping-off point but I'm certain there's things I'm missing!)

This is a very interesting possibility; thank you. Two things I'm thinking immediately (that you absolutely don't have to respond to! -- I'm writing them down firstly so I don't forget and secondly in case anyone has input but, again, absolutely not required from anyone):

(1a) this might make a good feature extension, rather than being something to bake in from the start?
(1b) if lists/groups get created, the way to display it that fits best with my preexisting prejudices is to have additional status options on the list: Admin/Moderator/Group1/Group2/...

(2) What would the workflow for creating groups look like? What set of pages would we expect to go through? How might they be laid out?

I feel like it might be a good idea to bake role-based access management in and then implement one-person privileges as roles (maybe even named after the person) — less technical debt incurred?

Having tick-boxes for (user * group) would be a useful display (and as groups are ticked/unticked the granular permission boxes would change accordingly) but I wouldn't think of that as the primary use case.

My use case would be:
1. Owner decides a new job exists in the community, e.g. "Archivist" who can do all the tag actions as well as edit memories.
2. Owner goes to community roles page, where they can see a list of roles, with role names, role permissions, and users authorized to act in that role. Each role has buttons to edit it and delete it, and there is a button to create a new role. There is no Archivist role already existing as far as the owner can see, so they click the New Role button.
3. Owner is presented with a new role form. There is a place to enter a display name, a place for comments, a list of privilege tick boxes and a user picker similar to the one used for building filters on individual user accounts. The owner ticks some privileges, adds some users, and clicks 'Add' to create the new role. Optionally, a check happens to verify that the role's permissions aren't identical to another role on add or save — it might be permissible but maybe the role editor could offer to merge identical roles.
4. If the owner wants to change who is an Archivist later or change Archivist powers, they can edit the role.

Any user can have any number of roles.
Editing the Administrator role is limited to adding or removing users, as they have to have all privileges.

This is essentially what is usually called "Role-Based Access Control" (https://en.wikipedia.org/wiki/Role-based_access_control).

I don't quite understand what the workflow/pages would be like so all I can say is that I wish admin privs were sorted into categories (tags, moderation, community control, etc.) so it'd be easier to find the priv you wanna edit.
Also +1 to the search username box.

I will put together screenshots in a few days' time and ping you when they're up!

I have been envisaging the Additional Privs page as inheriting from the Edit Community Members page, so it would have the same pagination and the same sort of sorting/searching options (as I have been thinking of it).

not-quick-but-very-dirty screenshots

Apologies for the character account, my phone browser is being a nitwit and won't switch.

I'm not an Admin of a game, but I am the main one for a few comms, and I can't see any point to non-admins having Admin privileges. If the comm has several types of admins (head, helpers, list, whatever), then different privilege levels there makes sense. But I don't see any reason to have the option for non-admins to get Admin privileges. It's too easy to abuse.

~lil_rebbitzen

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.

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?

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.

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!)

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.

Late to the party, but:

Would it be less scrolly if the categories for each group of powers (tags, entries, etc.) had their own page? So instead of a big list composed of all the people and all the possible powers, instead the "member privileges" page first lands on "moderator/administrator/excluded" statuses, with navigation to sections (in supergroups that are the actual page names that make sense in my head but that I can't actually articulate) based on "entries", "tags", "style", "memories", where someone can set individuals to have our not have permissions?

What I'm curious about is how to avoid being in the middle of the grid and accidentally giving the wrong privileges to the wrong person because we couldn't remember what columns did what and which users are on which rows.

not-quick-but-very-dirty screenshots -- which doesn't incorporate what you suggested here, but option 1 miiiiight want to end up doing that.

Which columns did what vs which row is which user: take a look and see what you think?

Flat | Top-Level Comments Only

Draft specification: more granular community permissions

THE CURRENT SITUATION

PROPOSED CHANGES

Points for discussion

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject