[UX] Add newly-created roles between the "Authenticated" and "Administrator" roles

[klonos]

This was suggested by @BWPanda in #4504 (comment)

...creating a new role adds it to the end of the list, after 'Administrator'. Assuming Drupal's recommendations about ordering apply to Backdrop too, maybe new roles should be placed between Authenticated and Administrator...?

The recommendation @BWPanda mentions above is a portion of the help text that was added as part of #4504:

To make the permissions page easier to navigate, we recommended ordering roles from the least permissive (Anonymous) to the most permissive (usually Administrator).

[klonos]

I initially attempted to implement this in a very simplistic way, by adding all new roles after the Authenticated role (setting their weight to 'weight' => $form_state['values']['roles'][BACKDROP_AUTHENTICATED_ROLE]['weight'] + 1), but testing by @jenlampton proved that this does not work as expected:

This doesn't behave reliably the way it's currently implemented. The first time you add new roles it's fine, because all the weights for the new roles are the same, so it places them alphabetically. But if you then re-order the roles, then try to add another new role, it behaves very strangely.

I think rather than trying to put it one position after the Authenticated role, we should try to place it one position before the Administrator role. Not only does this more closely match what people will be doing initially (since people would usually add more than one role in increasing order of permissions) but it will also work nicely when people return at a later date and add another new role.

From an implementation standpoint, we'll need to pull all the current roles by weight, insert the new one at the position where we'd like it, then save all the roles that have new weights. If we are assuming most people leave the Administrator role as the most permissive, in most cases this would mean only saving the new role, and the Administrator role. Alternatively, to place a role after the Authenticated role, we'd likely need to save them all.

Since this is no longer a simple change, I recommend we do this in another issue and keep this one to the text change. :)

[albanycomputers]

I came across this problem last week (October 2021) and there are more problems...

Backdrop V 1.20.1

I have created a "Student" role and it appeared after administrator so it inherited all of the admin's permissions.

I then moved the role after Anon and before Authenticated

and the role still has Admin permissions that can't be changed.

When you click on [Configure Role] then [Set Permissions] none of the permissions are set.

"View comments" is one that's visible in the images.

[klonos]

I have created a "Student" role and it appeared after administrator so it inherited all of the admin's permissions.

That's wrong (but also a separate issue). All roles should be created without any permission assigned to them.

...the role still has Admin permissions that can't be changed.

That's because you have assigned these permissions:

• either to the "Authenticated" role, which means that any other role (existing or created in the future) inherits them
• or to the "Anonymous" role, which means that every role inherits them (always)

That's how Drupal/Backdrop permissions work if assigned to any of these "special" roles.

When you click on [Configure Role] then [Set Permissions] none of the permissions are set.

That's a bug when editing a role individually. Can you please file a separate issue for it? I'm assuming that the JavaScript that takes care of auto-selecting checkboxes based on whether the respective permissions have been assigned to anonymous/authenticated fails, since there is only a single column of permissions loaded in that page.

[klonos]

...it seems to me that we should:

• "lock" the Anonymous role at the top, so that it is always the first role
• "lock" the Authenticated role after the Anonymous role (no role can be placed between Anonymous and Authenticated)
• "lock" the Administrator role at the bottom, so that it is always the last role
• any other role should go between Authenticated and Administrator

[albanycomputers]

...the role still has Admin permissions that can't be changed.

That's because you have assigned these permissions:

• either to the "Authenticated" role, which means that any other role (existing or created in the future) inherits them
• or to the "Anonymous" role, which means that every role inherits them (always)

Nope, it's a brand new install, I haven't changed any roles or permissions other than creating the "Student" role... I was experimenting with membership_entity on this install... but had the same problem on another install.

[albanycomputers]

It appears that while I have moved the "Student" roll which now has a weight of 1, it is still inheriting the "Authenticated" users permissions which can't be changed.

The only way to change the permissions of "student" is to re-order the roles so that "student" comes after "Authenticated" then change the permission of the "Authenticated" user, which then stops the inheritance to the Roles right of it.

Hope that makes sense :)

[albanycomputers]

When I then changed the permissions of "Student" the "editor" to the right did not inherit the permissions.

See "View Comments" permission.

[albanycomputers]

So it looks like the "Authenticated" user is hardcoded somewhere which means that the "Anonymous" and "Authenticated" roles need to be fixed and none moveable.

It looks like the logic for permission inheritance is messed up and assumes that Auth will always be after Anon roles and no other roles will have a weight lower than it.

While I understand the reasoning... the implementation and [UX] needs to be updated so that the logic works correctly or as mentioned above Anon and Auth roles need to be fixed in place.

[albanycomputers]

Is it possible for the Drag-handles to be removed for the two roles?

And if so, the Admin may as well be removed. - Not sure if that is in fact feasible or not.

[jenlampton]

Is it possible for the Drag-handles to be removed for the two roles?

Ooh, I like this idea!

And if so, the Admin may as well be removed. - Not sure if that is in fact feasible or not.

I have a lot of sites where I add a Developer role below it, and repurpose the Administrator role for "administrators" within the organization. A lot of folks have a hard time with Backdrop using that word for something different than they use it for internally, so I usually make it match :)

[ghost]

'Anonymous' refers to users of the site that aren't logged in (i.e. no roles at all). So it's unique and can't be inherited (doesn't make sense).

'Authenticated' refers to users that are logged in, therefore they may have 0 or more roles. These permissions are inherited by all other roles (other than 'Anonymous') since it's not possible for another role to have less permissions than a user with no roles.

So if you create a new role (e.g. 'Student') it's going to have at least the same permissions as 'Authenticated'. This can't be changed as it wouldn't make sense to.

Hope that helps.

[klonos]

'Anonymous' refers to users of the site that aren't logged in (i.e. no roles at all). So it's unique and can't be inherited (doesn't make sense).

Although the above is true, it may be confusing from an end user perspective. A better way to explain it is that if you grant a permission to the anonymous role, then any other role automatically inherits that permission. Another way to think about it is this: if anonymous can perform a specific task, then everyone (any role) can.

[ghost]

@klonos Not true:

[klonos]

Huh! ...I stand corrected then - I had this wrong all along 🤔

[jenlampton]

@klonos I think you got Anonymous mixed up with Authenticated. It is true that

if you grant a permission to the Authenticated role, then any other role (except Anonymous) automatically inherits that permission. Another way to think about it is this: if Authenticated can perform a specific task, then everyone (any role except Anonymous) can.

[albanycomputers]

It is also feasible that a site owner may want a Guest role, where they are allowed to do something but not everything an Authenticated user can do.

If this is ever the case, then the Authenticated User Role would need to be modified and reduce its permissions in order to allow a Guest Role, then another role would need to be added for Full Authenticated roles.

Probably a very very small use case, but still a valid one.

For example, the site may have content that only Members can see, so an Authenticated user can see and create new posts whereas a Guest user may only be able to view the Members only posts and not create them.

Hope that makes sense :-)

[klonos]

Yup, that's it @jenlampton ^^

[klonos]

That's a bug when editing a role individually. Can you please file a separate issue for it?

Never mind. I did that: #5336

[ghost]

For example, the site may have content that only Members can see, so an Authenticated user can see and create new posts whereas a Guest user may only be able to view the Members only posts and not create them.

@albanycomputers This is the wrong way to think about it. Authenticated isn't a normal role you can assign or unassign users. All users are authenticated. Therefore if you give Authenticated users the ability to create posts, all users will be able to create posts.

What you want is for Authenticated to be your Guest role, where they can view member-only content. Then you need a new role, like Editor, which can create posts. You'll have to decide how/which users are given the Editor role.

[albanycomputers]

Thanks @BWPanda I came to that conclusion :)

I would suggest that the Anon, auth and admin users be "Locked" into position so that they can't be repositioned with drag-handles :)

[ghost]

I agree re. Anon and Auth, but not Admin. There's nothing special about that role and no reason it can't be less permissive than a new, custom, more advanced role...

[bugfolder]

Also, in upgrades from D7, there's likely not a role with that title/machine name for Admin.

[klonos]

I agree re. Anon and Auth, but not Admin.

Wondering if there is an alternative/intuitive way to replace the entire "Administrator role" fieldset with some sort of "drag the admin role to the bottom of the list" functionality 🤔 ...I'll play around with some mockups to see if that works well.