I have tested this item ✅ successfully on dab6cb8

I have tested this item ✅ successfully on dab6cb8

RTC after two successful tests.

I disagree with this as a concept. I have several sites where I have plugins that are only targeted at public users - but I still want admins etc to be able to edit them.

@wilsonge you still can

what this pr is intended to do is to hide those plugins set to super user from being shown in the plugin manager to admins or managers. why you would ever want to do this or why you would ever have a plugin that only works for super users i have no idea.

overall I am not convinced this is a sensible change

I don’t think that’s the case though? I understand the intended effect but practically there is only setting with access level. Does the plugin get executed for the user or not. With this change if not they won’t see the plugin. Of course for super users this is probably ok (id need to test a bit) because of their global rights. But for non-super users not in the global access group I don’t see how they will now see things intended for people lower in the permissions chain, but they should be allowed to edit

look at this use case
suppose you want to restrict the system debug plugin to only Super Users
even if you set Super Users as the only Allowed Groups, if you log as an Administrator without this pr you are still able to edit/manage the system debug plugin

so what is the expected Access behaviuor ?

@alikon that answers my question - thanks

Expected result

log as Administrator
you should not see that plugin in the plugin list items

You are able to edit even after this PR,
the core.edit ACL decides if something is editable,

this PR just hides it, same thing in article manager
see more in my RFC issue

#17913

What @ggppdk says - this doesn't stop you editing (which gives a false sense of security), plus we have an ACL level for all plugins - which is core.edit at the plugin level. If you want to add in per-plugin acl for editing - then you need to do that as a thing. Trying to hack things in with the View Access Levels is totally abusing what that system is being used for

naive question:
please show me how you are still able to edit it ?

as for now we only have ACL level for all plugins so we don't have fine grained level permission for each plugin like modules/articles and to add acl per-plugin is outside the scope of this pr, even if i really wish such kind of PR come out

the scope of this pr is simple to hide items that you don't have proper access to, and honestly i don't think is abusing the system untill you clearly state :
what is the expected Access behaviuor/scope ?

Take the edit link of a plugin you can edit

I do not mean the edit form link that loads after the controller task does the edit task checkand adds the ID into session, so i do not mean

• administrator/index.php?option=com_plugins&view=plugin&layout=edit&extension_id=401

Instead use the link from plugin manager listing that points to the controller edit task
(find the edit link of a plugin that you can view and edit e.g. no 401)

• administrator/index.php?option=com_plugins&task=plugin.edit&extension_id=401

then in it replace the ID 401, with the ID of a plugin you can not view

Also why the change of this PR would prevent editing ?

• the change is just in query for record listing

how many average user do that ?

@ggppdk added a check for direct link like

administrator/index.php?option=com_plugins&task=plugin.edit&extension_id=401

updated
wasn't true, sorry got side-effects

right Access level check for direct link

Sorry but I'm not merging this. This is fundamentally wrong.