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.)
I think 2 is better for when communities scale up to many members - Alternity-size stuff probably needs and wants roles that they can assign and define themselves. With a set of useful defaults included that covers most use cases, small communities could also use roles effectively without having to spend time defining them.
I like the idea, where possible, to be able to assign blocks of permissions to roles, such that someone can receive full control over tags without having to assign individually "can add tags", "can edit tags", "can delete tags", "can rename tags".
That said, it still looks like the interface for assigning roles will be option 1, matrices everywhere. If there's a way we can help someone know where they are in the matrix at any given time, perhaps through some form of floating header for each role, I think that would be helpful to avoid mis-assigning roles.
As for assigning roles to non-members, it seems like a thing that should only be changeable by those with the power to change roles (admins and mods, maybe, get that by default), and that anything that involves either the members or non-members group checkboxes has a second page / pop-up saying "O Hai, this affects everyone. You sure about that?" to avoid a mis-assignment by accident.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
no subject
I like the idea, where possible, to be able to assign blocks of permissions to roles, such that someone can receive full control over tags without having to assign individually "can add tags", "can edit tags", "can delete tags", "can rename tags".
That said, it still looks like the interface for assigning roles will be option 1, matrices everywhere. If there's a way we can help someone know where they are in the matrix at any given time, perhaps through some form of floating header for each role, I think that would be helpful to avoid mis-assigning roles.
As for assigning roles to non-members, it seems like a thing that should only be changeable by those with the power to change roles (admins and mods, maybe, get that by default), and that anything that involves either the members or non-members group checkboxes has a second page / pop-up saying "O Hai, this affects everyone. You sure about that?" to avoid a mis-assignment by accident.