I don't see the usecases, can you give a few examples?

This sounds very dangerous

On 3 September 2016 at 06:50, Thomas Hunziker notifications@github.com
wrote:

I don't see the usecases, can you give a few examples?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#11903 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8RfUwDF3gRAlvkJ9eYoqLPX8MTUWks5qmQq2gaJpZM4J0Nao
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Sure.

1. You need to give special limited access to frontend for some items without giving the user Super user access OR access to the Category create/edit for that container

2. On a larger level, One use case could be that one needs Role based ACL across multiple extensions that are specific to certain items or categories. The same can be done with Joomla but would need creation of User groups on a Per Item level which would make it unmanageable. So this could be implemented by using the plugin trigger .. Basically let developers extend the Joomla ACL or implement a different approach if they wish to..

Generally this will offer developers a chance to implement customised ACL schemes as per their requirements - either in their own extensions or client projects.

Note that i'm proposing this to extend/override the way the 'Permissions Tab' in extensions is interpreted by Joomla. Let me know if this is enough.. or i can think of some more practical use cases

@brianteeman it would need a system plugin to use this.. so its not a security issue.. Only a developer who knows what they are doing can use it

But you are not proposing extending the acl you are proposing overriding
the acl. It doesn't seem a good idea to me at all to allow an extension to
override the acl settings that are set by the site owner. You're actually
making things more complicated as the acl settings displayed in the
permissions tab may not be the acl in use.

Well having the trigger would allow it to be extended or overridden. Will propose some code to demonstrate this. The plugin trigger itself would not really complicate things ..Because it would do nothing unless it is utilized by someone. However having it there would allow for extending the Permissions layer..

For accurate display on the permissions widgets, said triggers would have to be triggered whenever you're displaying the calculated ACL permissions. Anything that bypasses that is basically ignoring the user's configuration or making it next to impossible to verify what the actual ACL settings in use are (if you cannot reliably debug the ACL configuration with the existing widgets or debug tools in com_users then this has zero chance of acceptance). So as said above, this is very dangerous and should not be considered for core without a lot more thinking than "a plugin event can override a configured ACL decision".

I would also be hugely sceptical of this for security reasons.

Based on my understanding of ACL Case 1 can already be done with current ACL (if you set all the appropriate permissions for a special usergroup) If I understand what your Case 1 use statement implies, It's exactly what I've done this on sites I've managed.

As for Case 2 the only time I've had issues with "Role based ACL across multiple extensions" is when a 3rd party developer did not bake ACL into their extension. There are existing 3rd party ACL extensions listed in the JED that work around the general ACL management issues introduced when an extension doesn't have detailed ACL built in.

I'm not seeing a use scenario for this, I'm also sceptical of what this is really accomplishing and possible unforeseen security implications.

I think given the comments here I'm going to close this issue. If you want to come back with a more detailed proposal then do feel free. But I think the thing to take out of this is that we are pretty sceptical and unlikely to accept it.

Understood.. Will prepare a more detailed case and submit it for review. One line of thought i disagree with is that users will get confused as to whats shown in permission settings and whats applied.. that would be like saying lets remove the main system plugin triggers as that allows the system to behave differently if someone uses those in an incorrect way !

My argument simply is to provide the opportunity. As I said i'll revert with more cases