Are there any other modules apart from User Actions with this restriction?

At least Privacy Dashboard, Privacy check

just took a look into this and I can see that its display is restricted by code in the dispatcher

what is even more confusing to the End User is that when creating a user action log module it defaults to a viewlevel access of Super Users but it still lets you change that to any other viewlevel - even though the code in the dispacther invalidates that setting

The restricted modules aren't displayed for users with no permissions because their respective dispatcher classes have this filter ( or similar )
if (!$this->getApplication()->getIdentity()->authorise('core.admin')) { return; }
[ i've identified 4 modules like this: latestactions, messages, privacy_dashboard, privacy_status ]

But similar filtering is missing when the list is generated after the user selects 'new module'.
The method responsible for this is:
administrator > components > com_modules > src > Model > SelectModel.php > getItems(), which returns all administrator modules.

This can be overcome by adding a new optional tag in the XML file of restricted modules that declares the permission level requirement. And this tag can be used to remove the restricted modules from the list generated ( using an existing loop in getItems() which already parses the XML file for other metadata)

Is a fix like this okay? considering we have to add an extra tag in the XML file.

I dont believe the problem is to do with an admin user being able to create a module that they cannot see because the module is silently restricted to super users and ignores the view level setting below.

The exact same problem exists for a super user creating the module and setting the view level access so that a regular admin could see it. They cant because these modules are restricted to super users but the only way to know that is to read the code.

There absolutely is a UX problem with these modules but its not resolved by preventing an admin creating a super user only module. For me anyone who can create an admin module should be able to create any module BUT if the output of a specific module can only be seen by a super user then we need to indicate this in the admin UI when creating an instance of the module.

As these modules have a hard coded restriction then we need to indicate this restriction in the UI.

Below is a visual to indicate what I am talking about it. (Do not implement this in a PR its just an example)

@brianteeman when i was looking into this, it has come to my attention that a admin can also edit and trash modules that are restricted to super users, isn't this unideal ??

i dont see why

@brianteeman maybe I think this way because of my lack of experience as a end user, but why would a user that cannot see or preview the module, be able to edit and create / delete them ?
With the PR in this issue, restricted users can't create them anymore, so that leads to some inconsistency ( can't create but can edit / delete ) aswell

if your pr means that they can still edit existing but not create new instances then that's not desirable and doesn't address the issue

I have proposed an alternative approach #47331