Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
A new permission for accessing reports was recently added, but neglected to disable the errors on the admin screen when users didn't have access.
Attached patch checks for the 'access site reports' permission before printing the messages.
Comment | File | Size | Author |
---|---|---|---|
#5 | patch.txt | 1.76 KB | webernet |
report_access.patch | 1.85 KB | webernet | |
Comments
Comment #1
chx CreditAttribution: chx commentedWell, OK but is this going to a real problem...? If there is a problem "real" admins are going to fix... or so I thought. Anyways, that's an entirely different thread (if there is a permanent problem then what this message is good for... we need to be able to "ok" system status errors... anyways, different thread).
Comment #2
Gábor HojtsyCommitted.
Comment #3
Senpai CreditAttribution: Senpai commentedPatch applied and tested. Works as intended. I think this one should be committed, and I'm marking it as such. I did find an interesting side effect that's somewhat related to this patch, but can't be fixed by it.
When an anon or an authed user is given access rights to user_access('access site reports'), they can't actually go to the /admin/reports/status page. It seems to me that if a site admin is granting users the right to see this page by granting their users some 'access site reports' privs, something ought to be changed here. I'd venture a guess that 'access site reports' isn't supposed to allow users to see the /admin/reports/status page, so if I'm right, I'm suggesting that 'access site reports' be changed to 'view sitewide messages' instead.
Comment #4
Senpai CreditAttribution: Senpai commentedChanging the Status back to Fixed.
Comment #5
webernet CreditAttribution: webernet commentedAfter reading #3, I checked the permissions for /admin/reports/status and it uses 'administer site configuration' rather than 'access site reports'.
So, we need to either use 'administer site configuration' instead or change the status report to use 'access site reports'.
Attached patch uses 'administer site configuration'.
Comment #6
Senpai CreditAttribution: Senpai commented@wwwebernet: You were correct in assuming that users needed to be validated against the 'access site reports'. I recommend leaving things the way your first patch did, and changing the /admin/reports/status settings to check for an either/or with 'access site reports' OR 'administer site configuration'.
No, wait. That would lead to users who were allowed to see sitewide system messages being able to go to a page full of warnings about how to upgrade this or that module, but be unable to utilize any of the links on that /admin/reports/status page. Bad idea. I really think the problem here is stemming from the wording of the 'access site reports' role.
If it were to read 'view system messages', wouldn't that make more sense for all of us? Site admins would know exactly what that means, and any users who had been granted that obviously limited privilege would have no trouble grasping the fact that they don't get access to the status reports page when they only have 'view sitewide messages'.
Comment #7
Gábor HojtsySenpai: Unfortunately it is quite late now to change any permissions. For one, these might be used by contrib modules, but these are also translatable strings (which is the smaller problem). Actually, our permission names are also part of our API, so changing permission names is changing API. Can we clean up this situation without changing permission names?
Comment #8
webernet CreditAttribution: webernet commentedThe patch in #5 simply uses the 'site coniguration' permission (the one used for the status report page).
Alternatively, the permission for the status report could be changed to use the recently added 'reports' permission.
#5 is probably safer, since you might want to allow users to view logs, but not the status report.
Comment #9
Gábor HojtsyThanks, I verified that the site reports permission is indeed only used for the dblog pages, not the update module pages, where site admin access is required (somewhat logically, but not too clearly). So the patch in #5 is fine, and committed. Thanks.
Comment #10
(not verified) CreditAttribution: commentedAutomatically closed -- issue fixed for two weeks with no activity.