- First commit to issue fork.
- @vidorado opened merge request.
- ๐บ๐ธUnited States smustgrave
Believe this will need an upgrade path + update test. Currently with this change think you currently have access to you would have it ripped away. Believe proper approach would be that things shouldn't change for existing users but can be configured to take away after the fact by the site admin.
- ๐ช๐ธSpain vidorado Pamplona (Navarra)
@smustgrave I donโt see how users could suddenly lose their access. The only users who had view+edit access to roles in user edit forms were those with the "Administer permissions" permission, and that remains unchanged. As far as I understand, the only addition in this change is a read-only view of one's own roles for users with "View own account details" permission.
Regarding REST APIs, weโve only added an
AccessResult::allowed()
when the user has "View own account details", while keepingAccessResult::neutral()
otherwise, which aligns with the previous behavior.Could you clarify where exactly you see a potential permission loss?
Thanks!
- ๐บ๐ธUnited States smustgrave
You're adding a new permission that no one will have
- ๐ช๐ธSpain vidorado Pamplona (Navarra)
So, are you suggesting that the "View own account details" permission should be granted to authenticated users by default? That could make sense, but it would also mean that users would suddenly see their roles appearing in their own user edit forms.
If thatโs the intended behavior, an upgrade path should be implemented. However, Iโm not entirely sure if that would be the best approach. What do you think?