[Note, some basic behavior seems to have been adopted wholesale from phpGACL, http://phpgacl.sourceforge.net/. Their page explains some of the intent of ACO, ARO, AXO below. It doesn't seem like all of these behaviors are relevant to Joomla, which might explain these empty tables.]
Database Tables (thanks to http://www.bedre.no/images/stories/graf ... schema.png for the Database Schema which helps as a starting place):
- jos_core_acl_aro_groups : this defines the groups you see in the backend for user assignment, such as "Registered", "Author", and "Editor". This appears to be slightly hard-coded -- if you were to add or remove groups directly in the database, it looks like some of the behavior would be broken. Eventually I'd like to modify any files depending on hard-coded IDs (the _getBelow() function in libraries/joomla/user/authorization.php reference specific lft and rgt values 3 and 22). Additionally, the jos_users table seems to have both gid and usertype, which both pull data from this table. It seems like one of the two could easily be eliminated to reduce redundancy in the system.
- jos_core_acl_aro_section : this database table contains exactly one entry, 'users'. phpGACL indicates that this table is intended to define classes of requestors -- "browsers" or "users" or "servers", for example. I'm not sure how to make profitable use of this in Joomla.
- jos_core_acl_aro : this table seems to define a many-to-many relationship between assign specific user ids and specific aro_sections. So this would imply that while a user belongs to exactly one aro_group, he/she may belong to many aro_sections. Perhaps this could be removed without any real consequences.
- jos_groups : defines the content group types Public, Registered, and Special, that you see in the back end. I assume there is the obvious coupling between this and jos_core_acl_aro_groups, but it's not explicit anywhere.
- aco_section_value : this defines the component of interest - login, com_user, com_banners, etc.
- aco_value : seems to be a component-specific value - for example, login might define 'site', but com_user wouldn't know that value
- aro_section_value : this is always 'users' in this version and would presumably be tied to jos_core_acl_aro_section table above. Perhaps this informs the expected utility of that table?
- aro_value : this comes from jos_core_acl_aro_groups and indicates the minimum required group for access
- axo_section_value, axo_value : unused, mostly - com_content seems to define 'all' in the axo_section_value parameter. Input?
- return_value : a few values in com_user use this, seems to be from jos_core_acl_aro_groups, but I haven't dug around to find out why
So an untangling of the table together with a back end management system would probably make for a much more powerful ACL system. I think this is what JACL+ has done (or some similar enhancement), but it doesn't seem necessary to do it so that it breaks the existing modules, although I could be wrong on this point (I just started looking!). This is my goal, as I need to create a system that provides for several different classes of registered users to have access to different areas of the site, and within those classes I would like some users to have editorial access, etc.
If anyone has input on my understanding the current system (either corrections or reference to more information) please let me know. If anyone has a more painless way to introduce the behavior I'm looking for, please let me know.
I also read that an improvement of ACL is targeted at 1.6 -- is this something where scoping has already been done? If so, how can I become involved in that conversation rather than duplicating effort?