User tests: Successful: Unsuccessful:
For now, when use ACL permission (by access.xml file for define rule), it's not support to set an default value for permission.
This PR is updated version of #7517 with some modification base on these comments from last PR.
Don't have specific issue yet.
This PR for add an attribute "default" into an rule in access.xml file to set it default is "allow" or "denied", if default not specific, default rule will be "Inherit" as normal use. It's only effect when first edit permission rules and system will auto-select allow or denied base on "default" attribute in access.xml.
It's not has effect when this rule has been saved and open for edit.
Status | New | ⇒ | Pending |
Labels |
Added:
?
|
Title |
|
I agreed that inherits from "higher" levels is better for core permissions of an extensions.
But when use ACL system in data of an extension, I think this "default" attribute is necessary.
Example when I have an com_example which has categories and items. So, I applied ACL permission (view,...) for them and currently when client create item/category, they must set this permission to "Allow", if not this item/category can not view.
Well, view
obviously is a bad example for an action as this shouldn't be an ACL permission, but handled by the view levels.
I understand where this request is coming from, but still think it's a wrong solution.
When it comes to ACL actions, the actions should always be disabled by default (eg a guest should not be able to do it). You then activate it for the groups you want it. That's what the current behavior does. By default it is inheriting from parent groups and global settings, if those aren't allowing anything, then the action is denied.
If for some reason I need my extension to allow an action for a specific group by default, then I would just set those permissions during installation using a script file.
Category | ⇒ | ACL |
Status | Pending | ⇒ | Needs Review |
Setting to Needs Review based on the comments of @bakual so the CMS Maintainers can make a decision and we can either close or move forward with testing
I am closing this, the system is already complicated enough, I agree with @Bakual that this is not the right way to do it. Further more I am wondering what will be the result when a component get's updated, are the old defaults or the new defaults valid. Finally you can do it with a script file.
Thanks for the discussion and thanks @thongredweb for working on this.
Status | Needs Review | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-09-06 15:32:31 |
Closed_By | ⇒ | rdeutz |
Category | ACL | ⇒ | Libraries ACL |
Hi guys.
I am developing a component and searched/googled for "joomla acl default value" and this was the first result.
when i read the comments here, does that mean, that there is currently no way for an extension-developer, to set defautl values for his own components permissions? Then how would i be able to grant editors to allow action_xy by default for my extension?
An install.sql/.php script would not be good.
In my oppinion this does not make it more complicated. It just fits to the normal joomla-formfield-definitions that already allow a lot of attributes, and that is great. Because experienced developers will know, what to do with that.
@Robdebert can you please open a new Issue as write on closed issues didn't get much Notice.
Same comments apply as for the previous PR.
The premise is still wrong. The current ACL system has already a default value, it inherits from "higher" levels if nothing is specified.
Adding a default value to the XML counters the inheritance from the ACL system, and would imho make things worse, not better.