Closed (fixed)
Project:
Dashboard
Version:
2.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
20 Oct 2023 at 08:13 UTC
Updated:
30 Apr 2024 at 15:04 UTC
Jump to comment: Most recent
Problem/Motivation
Since #3359059: Improve Dashboard management permissions for admin users, it is necessary to have explicit permissions to access to dashboards in /admin/dashboard. However, no roles are assigned by default to user 1. Therefore, it is not possible to assign any dashboard to that user unless a specific role is assigned.
This should be solved once #540008: Add a container parameter that can remove the special behavior of UID#1 is fixed.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork dashboard-3395483
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
plopescComment #3
plopescGiven that progress in the issue this one is postponed on #540008: Add a container parameter that can remove the special behavior of UID#1 is not going as fast as we would like to, we decided to work on this one to unblock it.
Comment #5
plopescAfter some thinking, created a MR where the logic has been modified to check for the specific permission instead of checking if the permission belongs to any of the user roles.
The result of this change is hat user 1 will have access to all the published dashboards, while the res of users logic will remain as it was.
I think this is a compromise solution until the arrival of #540008: Add a container parameter that can remove the special behavior of UID#1.
Comment #6
penyaskitoGiven how close #540008: Add a container parameter that can remove the special behavior of UID#1 might be to land, this looks like the right call.
Comment #7
penyaskitoOh, so close that it landed a week ago! Still current behavior remains by default though.
Comment #8
plopescYep, I believe we will still to use this workaround - or a different one - for now.
Comment #9
penyaskitoI like the MR, is this something we can add a test for?
Comment #10
plopescGood point!
I don't know well how to replicate the user 1 behavior in kernel tests after #540008: Add a container parameter that can remove the special behavior of UID#1.
Actually this MR is agnostic and gives the actual responsibility to the site administrator.
If they decide to give superpowers to user 1, they'll access to all the dashboards.
If user 1 is not empowered, it would behave like any other.
Don't think we need to add extra tests to confirm the default behavior.
If you feel safer having them, we could explore how to make it possible.
Comment #11
plopescLGTM!
Comment #13
plopescMR merged. Opened #3441321: Define specific tests for disabled super user access policy to implement extra tests for disabled super user access policy once it is added to a stable release.