[#48593] - [6.2] Display the permissions for the Super User group correctly
- Ready to Commit
- Medium
- Build: 6.2-dev
- # 48593
- Diff
- brianteeman:permissions
User tests: Successful: Unsuccessful:
Pull Request resolves #44416 .
- I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.
Summary of Changes
The Permissions Debugger displays incorrect permission results when checking the Super Users group.
The group debugger uses Access::checkGroup() to determine each permission. However, User::authorise() treats a user as a Super User when their group has the core.admin permission. Once a user is identified as a Super User, authorise() returns true for all permission checks.
As a result, the permissions displayed for the Super Users group do not match the effective permissions of a user belonging to that group. The group debugger can therefore display permissions as denied even though a Super User can perform the action.
This change checks whether the selected group has core.admin. When it does, the permission checks in the group debugger are treated as allowed, matching the behaviour of User::authorise() and the actual effective permissions of a Super User.
Testing Instructions
Users>Groups>Permissions and select the Super Users group.
Check the displayed permissions
Also select a normal user group and verify that its existing explicit allow, explicit deny and implicit deny results are unchanged.
Actual result BEFORE applying this Pull Request
The Permissions Debugger for the Super Users group displays all permissions as denied even though they can perform those actions.
Expected result AFTER applying this Pull Request
The Permissions Debugger correctly displays the effective permissions of the Super Users group as allowed.
Link to documentations
Please select:
-
Documentation link for guide.joomla.org:
-
No documentation changes for guide.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_users |
| Labels |
Added:
PR-6.2-dev
|
||
I have tested this item ✅ successfully on 1bfe3d0
With this PR, Permissions Debugger correctly displays the effective permissions of the Super Users group as allowed
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
I have tested this item ✅ successfully on 1bfe3d0
Tested with JBT
- Seen before all permissions are red in Users > Groups > Permissions > Super Users group
- Applied PR
- All permissions are green in Users > Groups > Permissions > Super Users group
- All red for Public
- Some green, some red for Publisher
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
I have tested this item ✅ successfully on 1bfe3d0
Tested with JBT
- Seen before all permissions are red in Users > Groups > Permissions > Super Users group
- Applied PR
- All permissions are green in Users > Groups > Permissions > Super Users group
- All red for Public
- Some green, some red for Publisher
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
I have tested this item 🔴 unsuccessfully on 1bfe3d0
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
I have tested this item 🔴 unsuccessfully on 1bfe3d0
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
I have tested this item 🔴 unsuccessfully on 1bfe3d0
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
needs changes — Super Users are shown as allowed, but for every other group "Not Allowed" (implicit deny) is now displayed as "Forbidden" (explicit deny).
Setup: default install plus one explicit deny (Articles → Options → Permissions → Publisher → Delete = Denied), so that all three states exist.
Verification
Users → Groups → Permissions, 92 assets × 8 actions = 736 cells per group, counted as Allowed / Forbidden (explicit deny) / Not Allowed (implicit deny):
| Group | Before | With PR | With suggested fix |
|---|---|---|---|
| Super Users | 0 / 0 / 736 | ✅ 736 / 0 / 0 | ✅ 736 / 0 / 0 |
| Public | 0 / 0 / 736 | ❌ 0 / 736 / 0 | ✅ 0 / 0 / 736 |
| Publisher | 369 / 11 / 356 | ❌ 369 / 367 / 0 | ✅ 369 / 11 / 356 |
| Manager | 479 / 0 / 257 | ❌ 479 / 257 / 0 | ✅ 479 / 0 / 257 |
Finding — implicit deny becomes explicit deny for all non Super User groups
Access::checkGroup() returns true, false (explicit deny) or null (implicit deny), and the template tests === null for the implicit state. checkGroup(...) || $isSuperUserGroup always yields a boolean, so null turns into false: the ⊖ "Not Allowed" icon is replaced by ✕ "Forbidden" everywhere and the two states can no longer be told apart. This is the "existing explicit allow, explicit deny and implicit deny results are unchanged" check from the testing instructions.
Suggested fix
$asset->checks[$name] = $isSuperUserGroup ?: Access::checkGroup($groupId, $name, $asset->name);Tested: results in the last column of the table above.
I have tested this item 🔴 unsuccessfully on 1bfe3d0
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
needs changes — Super Users are shown as allowed, but for every other group "Not Allowed" (implicit deny) is now displayed as "Forbidden" (explicit deny).
Setup: default install plus one explicit deny (Articles → Options → Permissions → Publisher → Delete = Denied), so that all three states exist.
Verification
Users → Groups → Permissions, 92 assets × 8 actions = 736 cells per group, counted as Allowed / Forbidden (explicit deny) / Not Allowed (implicit deny):
| Group | Before | With PR | With suggested fix |
|---|---|---|---|
| Super Users | 0 / 0 / 736 | ✅ 736 / 0 / 0 | ✅ 736 / 0 / 0 |
| Public | 0 / 0 / 736 | ❌ 0 / 736 / 0 | ✅ 0 / 0 / 736 |
| Publisher | 369 / 11 / 356 | ❌ 369 / 367 / 0 | ✅ 369 / 11 / 356 |
| Manager | 479 / 0 / 257 | ❌ 479 / 257 / 0 | ✅ 479 / 0 / 257 |
Finding — implicit deny becomes explicit deny for all non Super User groups
Access::checkGroup() returns true, false (explicit deny) or null (implicit deny), and the template tests === null for the implicit state. checkGroup(...) || $isSuperUserGroup always yields a boolean, so null turns into false: the ⊖ "Not Allowed" icon is replaced by ✕ "Forbidden" everywhere and the two states can no longer be told apart. This is the "existing explicit allow, explicit deny and implicit deny results are unchanged" check from the testing instructions.
Suggested fix
$asset->checks[$name] = $isSuperUserGroup ?: Access::checkGroup($groupId, $name, $asset->name);Tested: results in the last column of the table above.
Screenshots
Users → Groups → Permissions, 1440px. "Before" = same test site with DebuggroupModel.php from 6.2-dev. "Suggested fix" = this PR with the one-line change from above.
Icons: ✓ Allowed, ✕ Forbidden (explicit deny), ⊖ Not Allowed (implicit deny).
Super Users — the fix works
Before: everything ⊖. With PR and with the suggested fix: everything ✓.
| Before | With PR | Suggested fix |
|---|---|---|
 |
 |
 |
Public — implicit deny shown as explicit deny
Before: everything ⊖. With PR: everything ✕. Suggested fix: ⊖ again.
| Before | With PR | Suggested fix |
|---|---|---|
 |
 |
 |
Publisher — explicit and implicit deny can no longer be told apart
This group has one real explicit deny (Articles → Delete, set for the test). Before: that deny is ✕, everything else not allowed is ⊖. With PR: all of them are ✕. Suggested fix: as before.
| Before | With PR | Suggested fix |
|---|---|---|
 |
 |
 |
Manager — same effect without any explicit deny
Before: ✓ and ⊖ only. With PR: every ⊖ is ✕, although nothing is explicitly denied for this group. Suggested fix: as before.
| Before | With PR | Suggested fix |
|---|---|---|
 |
 |
 |
| Status | Ready to Commit | ⇒ | Pending |
Moving back to pending due to a failed test. Thanks, @tecpromotion, for your detailed testing!
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
Moving back to pending due to a failed test. Thanks, @tecpromotion, for your detailed testing!
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
Updated with suggested change
I have tested this item ✅ successfully on 9ac2fb1
Tested with JBT
- For Super User all group permissions are green Allowed
- For Public all red Not Allowed, just as before the PR
- For Guest all red Not Allowed, just as before the PR
- For the Manager some are shown in red as "Not Allowed" and others in green as "Allowed", just as before the PR
- For Publisher some are shown in red as "Not Allowed" and others in green as "Allowed", just as before the PR
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
I have tested this item ✅ successfully on 9ac2fb1
Tested with JBT
- For Super User all group permissions are green Allowed
- For Public all red Not Allowed, just as before the PR
- For Guest all red Not Allowed, just as before the PR
- For the Manager some are shown in red as "Not Allowed" and others in green as "Allowed", just as before the PR
- For Publisher some are shown in red as "Not Allowed" and others in green as "Allowed", just as before the PR
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
I have tested this item ✅ successfully on 9ac2fb1
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
I have tested this item ✅ successfully on 9ac2fb1
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
I have tested this item ✅ successfully on 9ac2fb1
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
I have tested this item ✅ successfully on 9ac2fb1
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
I have tested this item ✅ successfully on 9ac2fb1
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
Super Users are shown as allowed, every other group is displayed exactly as before the PR.
Setup as in my first test: default install plus one explicit deny (Articles → Options → Permissions → Publisher → Delete = Denied).
Re-test
Users → Groups → Permissions, 92 assets × 8 actions = 736 cells per group, counted as Allowed / Forbidden (explicit deny) / Not Allowed (implicit deny):
| Group | Before | 1bfe3d0 | 9ac2fb1 |
|---|---|---|---|
| Super Users | 0 / 0 / 736 | 736 / 0 / 0 | ✅ 736 / 0 / 0 |
| Public | 0 / 0 / 736 | ❌ 0 / 736 / 0 | ✅ 0 / 0 / 736 |
| Publisher | 369 / 11 / 356 | ❌ 369 / 367 / 0 | ✅ 369 / 11 / 356 |
| Manager | 479 / 0 / 257 | ❌ 479 / 257 / 0 | ✅ 479 / 0 / 257 |
| Administrator | 549 / 3 / 184 | not tested | ✅ 549 / 3 / 184 |
The finding from the first test (implicit deny shown as explicit deny) is resolved.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.
I have tested this item ✅ successfully on 1bfe3d0
With this PR, Permissions Debugger correctly displays the effective permissions of the Super Users group as allowed
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48593.