Ok, having done a little more research on phpGACL (read http://phpgacl.sourceforge.net/manual.pdf
), it looks like it is a reasonable way to offer slightly more configurable and slightly more fine-grained access control without changing what is there and seems to work. I saw some of the comments against the full phpGACL, and I don't know what to think of them yet -- however, since my bias is toward doing as little work as possible, I'm not going to swim upstream and propose an entirely different ACL model -- even assuming I was well versed enough to do so.
Here is what I'm thinking:
Observation 1: ARO
ARO - "Access Request Objects" -- things that request access. In phpGACL, these have a "section" and a "value", and may be nested. The section is used in a degenerate way in Joomla, as it is always 'users'. The "value" is a group, giving the familiar arrangement of:
... where each child inherits rights assigned to the parent. The hard-coding I mention earlier is used to prevent people from choosing "Public Front-End" or "Public Back-End" as actual groups. This is a hack and could be fixed in a number of ways - I propose one in Action 1.
* Action 1: Add section_id to jos_core_acl_aro_groups table, use acl_aro_section to define section names, remove acl_aro after removing any stray references to it. This fixes the "public front-end" and "public back-end" hack, as they become proper section names associated with their respective levels. This also allows us to add our own custom groups and sections --> NOTE <-- this will probably break some existing software unless a hack is put in to map or fake existing categories, or Action 6, below, is implemented as well.
Observation 2: ACO
ACOs, "Access Control Objects", seem to be a pretty good mapping that allow components/plugins/what-have-you to register their own actions and capabilities. I don't see any reason to modify this except maybe it would be good to put them in the database someday and have a more consistent documentation requirement so we can find out which components support which access-restricted actions.
Observation 3: AXO
AXO, "Access eXtended Objects", are largely ignored in the implementation today (I need to do a little more searching to confirm this). However, as described in phpGACL, they are perfect for offering a more detailed level of control over content (and possibly other areas if that makes sense). Today, the functionality is being offered by the "jos_groups" table, which is a very weak version of the AXO capability. I think this can be fixed without breaking the system as it stands:
* Action 2: Change meaning of jos_groups to be AXO values; maybe make a new table with an alias to the old one, maybe just be clear about the use and allow developers to do their own translation in the short term.
* Action 3: Add a section_id and axo_section table to allow components to register their own axo values (previously jos_groups), just like AROs after Action 1. This allows us to restrict this behavior to the com_content component initially, and not confuse anyone else.
* Action 4: Create the ability for admins to define their own content access groups by defining new AXO values for the com_content component and assign them to content sections (or articles, I suppose, but sections is enough for my needs).
Observation 4: This is probably enough for a slightly more customizable capability: now I can define some of my own custom user groups (AROs), and content access groups (AXOs), while the components define the relevant actions (ACOs), as they currently do. It results in slightly more complicated
I'll probably stop here, but the next steps to getting a completely flexible phpGACL implementation should also be:
* Action 5: Define an "Access Policy" back-end component that allows definition of linkages among AROs, ACOs, and AXOs, as described in the ending pages of the phpGACL manual. This is directly supported in the phpGACL check_acl function, so once the control panel is built to edit them, the logic of checking them should already be done.
* Action 6: allow users to belong to more than one aro_group -- create a new table to allow many-to-many between the users table and the aro_groups table. At the very least this is valuable for backward compatibility; more complicated ACLs are also possible (caveat in the phpGACL document that this now permits ambiguous access rights; should probably be looked into more carefully).
That's all for now. I'll keep you updated on progress.