More granular community permissions: mocked-up screenshots

[kaberett]

These are not-as-quick-as-I'd-like-but-definitely-dirty, and are based on our previous discussion about specification and workflows. It's been a while since that post, so I'm making this one for the pictures; in summary, there are two options for how to go about managing this.

In all cases, I should have used "Community control" rather than "Additional Privileges" but I... absolutely could not face going back and editing everything again when I realised, sorry. And in all cases I haven't provided complete lists of privileges/privilege bundles -- those exist in comments on the previous post, and will get put into the final composite spec properly. (I... am being pretty slapdash about this, sorry, but if I try to get everything Just Right at this stage what will actually happen is I'll spend the next six months hyperventilating about how y'all will kick me off the project if I use the wrong font and nothing more will happen, so this is a sketch for the idea of the thing, sorry.)

Also in all cases, there should be another header row under "non-members", but I ran out of steam, see above, sorry.

Option 1: tickbox matrices as far as the eye can see

This is the option laid out in the last post: replace "Administrator" and "Moderator" checkboxes with a "Community Control"/"Additional Privs" box, and an Additional Privs/Community Control page with a bunch of tickies (with "Administrator" acting as a master ticky, though that isn't illustrated here).

/communities/list gets an additional link (with better layout):

Edit Community Members gets a slightly different set of tickboxes:

And we get one new page, giving us a large matrix of tickboxes (which will be paginated, but which probably needs an extra couple of columns to get all the privs bundles in):

Option 2: Define community control roles

This was suggested in comments on the previous post, as a way of creating custom roles/priv bundles as required by the community. In addition to the Additional Privs/Community Control link, /communities/list would then also have "Manage Roles" as an option. Which members were displayed on the Additional Privs/Community Control page would again be controlled by the checkbox so labelled on the Edit Community Members page, as for option 1.

Defining roles ("Manage Roles") is currently envisioned to look like managing filters (nb per introduction this does NOT contain all possible privileges):

The check-box matrix would then be rather more manageable:

Further thought is needed about what restrictions should be placed on assigning roles to *all* non-members (as distinct from assigning roles to *specific* non-members, who in the Edit Community Members page would have "Additional Privs" but not "Member" checked, as is currently the case with community admins who are not community members, and so on.)

Documentation

Priv bundles will need explaining. This could happen on-page, in dedicated FAQs, or both. (Probably both.)

Your thoughts?

Comments welcome, but have an easy poll:

Poll #16996

Open to: Registered Users, detailed results viewable to: All, participants: 27

View Respondents

Which workflow do you prefer?

View Answers

Option 1: matrices as far as the eye can see
5 (18.5%)

Option 2: roles-based community controls
20 (74.1%)

Something else, which I will explain in comments
2 (7.4%)

Thanks heaps for your patience, folk!

Comments

[denise]

The more I look at it, the more I like the 'roles' type setup -- I think that will be more usable for people long-term (albeit with a slightly higher setup up-front, but still), and it will be way less overwhelming on the full-membership list, assuming comms only set up a few roles.

[kaberett]

Really REALLY glad the screenshots are helpful for you :-)

Roles does make a lot of sense and I am super-glad to the users who suggested them and thrashed them out in comments on the previous post!

If we do it this way we also have (in future) the option of complicating things further/making stuff Yet More Granular, but if you're happy with this set-up and the majority of users are happy with this potential set-up and nothing super ground-breaking comes into comments here, I'm going to try to get this properly specced up (including actual lists of all the priv bundles x_x) and up on GHI byyyyyy early October, say. (And then maybe see if I can't get someone to implement it during the contributor weekend in early November. :-p)

[azurelunatic]

I would really like a way to highlight Powers Not Assigned To Any Role, for troubleshooting/discovery purposes. Perhaps as an autogenerated role which can't be assigned?

[kaberett]

So all powers are axiomatically assigned to Administrator; it's never the case that no community-management-human can do a thing. Does that address your concern, or are you specifically thinking that it's useful to suggest to every community that they want non-Administrator roles that cover every privs bundle?

[azurelunatic]

The case I'm thinking of is less No Person Can Do This Thing and more I Wish That Were A Permission Oh Wait WTF When Was That Added, I guess

[kaberett]

Hmm. So if we go roles-based, every time you create a new role you'll get the full list of priv bundles in the Not In This Role column (and every time you tweak a role, you'll see a list likewise); plus there'll be a list/glossary of priv bundles hopefully both on the page itself (short version) and in a linked FAQ (longer version).

Which is obviously not to say you're wrong! Just that I'm still not quite grokking (which might well be me failing to recognise other's viewpoints because autism etc etc :-p) and it sounds like a fair bit of complexity for a thing I'm Not Grokking? I am perfectly happy to put it in the spec nonetheless if told to!

[azurelunatic]

Ah! I am not thinking in a column in the grid, I was thinking a Not In Any Other Role group in the bundler tool, a group which doesn't show up in the grid.

[kaberett]

I think I was unclear? I did mean on the Roles-defining page, and by "column" herein meant the "Role cannot:" and "Role can:" scrollyboxes in the fourth screenshot.

[azurelunatic]

I guess what I *really* want is, some easy way for people to compare the contents of roles and figure out what's overlapping and what's missing. Maybe a third page, or another section?

(This is also probably a good time for me to explicitly mention that while I have Strong Opinions, I only get to make design decisions about spamwhacky stuff, and that's only unless D says different...)

[kaberett]

(Sure, but me Not Getting It doesn't mean it wouldn't be considered a generally-useful tool!)