[#47295] - [5.4] Hide restricted admin modules from unauthorized users in selection list
- Pending
- Medium
- Build: 5.4-dev
- # 47295
- Diff
- krishnagandhicode:fix/46896-hide-restricted-modules
User tests: Successful: Unsuccessful:
Pull Request resolves #46896
- 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
Following the discussion in the issue, I implemented this by adding an optional <permissions> tag to the module xml.
Added <permissions>core.admin</permissions> to the xmls files for mod_latestactions, mod_privacy_dashboard, mod_privacy_status and for mod_messages added core.manage
updated SelectModel::getItems() in com_modules to parse this tag(and the optional asset) and unset the module from the list if $user->authorise() fails.
Updated: updated ModulesModel::translate() in com_modules. applied the same XML permission check to the main module managrr list.
Note : if the maintainers prefer not to introduce a new XML tag, I am happy to update this PR to use a hardcoded array in the Model instead. I appreciate any feedback on this architectural choice
Testing Instructions
Described in #46896
Actual result BEFORE applying this Pull Request
Restricted modules do appear in the list for standard administrators and cause confusion since they disappear from the dashboard after creation.
Expected result AFTER applying this Pull Request
Log in as the Administrator.
Go to Home Dashboard -> Add module to the dashboard button (+).
Result: "Action Log", "Privacy Dashboard", and "Privacy Status" are hidden from the list.
messages is still visbile because admins usually have core.manage access to com_messages.
Recording.2026-03-07.133747.mp4
Now test the new asset:
login in as super user.
Global Configuration -> messaging -> permissions
now change "Access Administration Interface" to Denied for the Administrator group.
now logout from super user and login again as administrator and check the module list and "Messages" is now hidden too.
After.PR.mp4
finally Log out and log back in as a Super User.
again go to Add module to the dashboard button.
Result: All four modules are visible and can be created.
Also by the last update now when you login in as admin and look for existing modules(system -> under manage -> administrator modules) you will not find the super user only modules there, which is available without the PR( without pr you can see, edit and trash those modules).
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_modules Modules Front End Templates (site) |
| Title |
|
||||||
| Labels |
Added:
PR-5.4-dev
|
||
| Category | Administration com_modules Modules Front End Templates (site) | ⇒ | Administration com_modules Modules |
I have tested this item ✅ successfully on b10307a
After applying the PR the "Action logs module" was only visible for super administrators
Found by clicking on Home->Add module to the dashboard on the bottom
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47295.
I have tested this item ✅ successfully on b10307a
I have tested this successfully! Thanks @krishnagandhicode!
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47295.
I have tested this item 🔴 unsuccessfully on b10307a
after applying this patch:
When trying to create a new module (as a user in the administrator user group), the module 'messages' is hidden.
But according to the dispatcher class of this module it is visible to an administrator.
Filtering based on component specific permission should also be implemented (currently it is only global) and this will fix the problem with the module 'messages'
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47295.
Thank you for testing and catching that, will update the PR v soon.
| Labels |
Added:
RMDQ
|
||
I have updated the PR description and testing instructions(Mainly the After Applying patch part).
PR is ready for human test again.
Note : if the maintainers prefer not to introduce a new XML tag, I am happy to update this PR to use a hardcoded array in the Model instead. I appreciate any feedback on this architectural choice
@krishnagandhicode We (maintainers) will discuss that and come back to you with a result hopefully Wednesday next week. Introducing a new XML tag could also mean that it counts as a new feature. As 6.1 had already feature freeze with their 6.1.0-beta1, that would mean the PR would have to be rebased to 6.2-dev. But wait with that until we have discussed it.
Of course people can already test this PR. Worst case is that it will need new tests when it needs some code change.
@krishnagandhicode looks good 👍 , i will formally test this after the maintainers opinion
from your comment on the issue am I to understand that this only prevents a non-super user creating a new instance of a module and that they can still edit an existing module that has ths restriction? If so then this isnt a good solution
@brianteeman, @hiteshm0 you are right. I just checked it locally, a administrator can indeed see , edit, and trash an existing "Action Log" module from the main manager list.
Brian currently this Pr only patches 'SelectModel' to filter the creation list - which was the original scope of the issue.
But seeing this UX inconsistenncy, should I expand the PR to also filter these restricted modules out of ModulesModel -the main management list ? (if that's doesn't block admins from doing things they are actually supposed to do ?)
Welcome to the world of contributing to Joomla as opposed to fixing something for an individual web site. There is always more to consider than the limited scope defined in the bug report.
I have updated(expanded) the PR, now if a user lacks the dispatcher permission(admin) then the restricted modules will be strictly not accessible (either exiting moduls or creating new modules).
About the confusion for super user being able to give access to super user only modules to admin - that form is generic in everycase - so yes adding that text to these modules could be a good solution to handle that as well (but only adding that text and still allowing admin to see, edit and trash the exiting modules does not seem to be good user experinece to me)
I believe a hybrid approach using both the PRs(this and #47331) would be a good solution.
I am not so experienced with Joomla ( I am learning) - If I have understood something wrong please correct me.
@krishnagandhicode can you check if using core.admin inside the permission tag is the right approach for mod_messages ?? the dispatcher class for mod_messages is much more lenient
