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

[xwingace]

The tickybox assignment of roles looks... dangerous, not so much for these (default?) roles, but in the case where a community defines a lot of different ones (or basically these but with very long names) for whatever reason. That matrix would get wider and wider and no more readable.

No real idea for a solution, just a feeling that drop-downs or a downwardly expanding 'More roles' feature might help.

XWA

[kaberett]

*chinhands*

Issue with dropdowns: Each human wants to be able to have multiple roles, if necessary.

Issue with Roles being listed vertically rather than horizontally: different behaviour to Edit Community Members page, plus current behaviour on ECM page is to have up to 100 users per tickbox-matrix page, and do pagination on the number of users not the number of roles. (This is also how the Manage Circle page works, approximately, albeit with slightly different layout.)

UI people, can you think of a sensible option for "x roles per page"?

(I suppose the other option is instead to duplicate the Manage Roles page again, only this time *actually* treat them like filters -- Roles in the Filters box, then "list of people with Community Control ticked who do not have this Role" versus "list of etc who do", but I think that would have the risk of being confusing and I... would prefer the matrix of tickboxes for my community management purposes, so. Announcing my biases to the world while thinking aloud at you, etc!)

[denise]

I think we can avoid too-wide columns just by restricting the possible length of role names.

[kaberett]

I think that still has the issue on the Additional Privs page (if kept as a checkbox) that if a community designates, say, 20 different Roles, that'll be a very wide matrix. There's the option of putting an arbitrary cap on the number of Roles that can be defined, but honestly I kiiiind of feel like if community administrators want eleventy billion different Roles then to some extent they can deal with that not being presented super gracefully when it comes to assigning them?