Panel\Field::role() allow passing $roles

[distantnative]

Description

Summary of changes

• Revert User::roles() action parameter, that was a turn in the wrong direction
• Consistently use $kirby->roles()->canBeCreated() for when creating a user, $user->roles() when changing the role of a user
• Fix User::roles() with simplified logic for changeRole permission checking
  • If no permission to change role of this user, return only current role
  • Otherwise return all roles that can create (implied that if a user can create role A and B, they also should be able to change someone to role A and B)
• Panel\Field::role():
  • Allow passing roles collection to
  • Use roles collection methods for logic instead foreach
  • Only hide field if no option available. Otherwise show as radio button for transparency which role is chosen.
• User create dialog preselects first role option instead of the role of the current user (or is the assumption users create mostly other users with the same role as theirs?)
• UsersView: use new canCreate prop that also takes available roles count into consideration, not just permission
• UserView and UserProfile: new canChangeEmail, canChangeRole, canChangeName and canChangeLanguage props instead of working with permissions array
  • Allows to take available roles count into consideration for canChangeRole

Reasoning

Different action contexts will have a different set of roles available to display. Instead of putting that logic into the Panel\Field::roles() UI method, it should rather allow to pass the appropriate roles collection to this helper method.

Previous PRs introduced User::roles($action) - that was a turn in the wrong direction as the create and change role actions have very different relations to the user object. For creating, $kirby->roles() is actually the right base, not $user->roles(). For these cases, one should use $kirby->roles()->canBeCrreated() then. This allows to simplify $user->roles() to always only return the available roles for a user to be changed to.

Furthermore, our Panel UI had some problems where it only focused on the general permission, but not the actual available role count. While a user can have the general permission, blueprint options for specific roles can still lead to situations where no roles are available. The UI needs to consider that.

Changelog

Fixes

• Panel UI fixed for create and changeRole permissions and user options
  user permissions: support for options broken #5147
  user permissions: changeRole has no effect #5146

Enhancements

• Role always shown when creating a new user, even if only one role available

Ready?

• In-code documentation (wherever needed)
• Unit tests for fixed bug/feature
• Tests and CI checks all pass

[bastianallgeier]

I'm not entirely sure why, but when I test this PR in the sandbox lab, I can only add users with admin roles. The other roles vanish from the field.

[distantnative]

@bastianallgeier It's because of this https://github.com/getkirby/kirby/blob/develop-minor/src/Cms/User.php#L588-L591 - for the last admin we exit here too early. That's fine for changing the role, but not creating. Maybe we need to first merge #6657 and then can remove that check.

[bastianallgeier]

While testing this, I saw that we still have some kind of logic issue when the permissions to change the role of any user is set to false, but the permission of the own account is set to true.

permissions:
  users:
    changeRole: false

When you go to the account view, the Role button is active (which is already wrong), but the dialog will show without the role field.

[distantnative]

@bastianallgeier Do you have more context of your setup for me to reproduce?

I have two users. One admin, one client. Logged in with the client.

blueprints/users/client.yml:

permissions:
  users:
    changeRole: false

But account view seems right: Can change role, because user.changeRole permission is not set to false and the dialog also shows the options.

EDIT: correction: the button in the user profile is enabled, the dropdown button is disabled 😑

[bastianallgeier]

I've used the lab setup in the sandbox and added:

title: Editor

permissions:
  users:
    changeRole: false

to the editor blueprint

[distantnative]

@bastianallgeier

and then created an editor user? By default, the lab setup only has the admin user if I am not mistaken.

[bastianallgeier]

Oh, yes forgot to mention that. I've created a new editor and logged in as them.

[distantnative]

@bastianallgeier what do you think about this b5db86a to solve the UI state for the user profile button? Alternatively, we could simplify it a lot if we just look at the permissions and allow the button to be enabled/the dialog to open but then just show one available role (the current one).

There still is a harder problem with User::roles() not delivering the right roles for the current user themselves.

[distantnative]

I have reworked the logic. Going with $user->roles($action) was a wrong turn, I reverted it and my tests now seemed to be consistent in behavior.

[bastianallgeier]

Despite the remaining conversation on Discord, I consider this PR done. If we decide to extend the permission dependencies, it would need to be done in a separate step anyway.