Still not a fan of introducing what is in essence a styling element with no ACL functionality into the ACL XML schema. As pointed out on the corresponding issue, a better approach which actually fits this purpose AND the ACL system would be to have some kind of grouping system.

@mbabker

Thanks for reviewing this, if you have some suggestion on implementing this differently , then i would try to implement

Extensions with long listing of ACL rules look like very difficult to configure and also i would use the word "intimidating"
e.g. i have 2 pages of permissions in component

With headings (that also have levels like HTML's h1, h2, h3) they really become readable / understandable

Currently i am using a JS workaround to manipulate the DOM and inject the headings

The other choice i was thinking lately , which looks like a better alternative is to load an override of class:
JFormFieldRules
libraries/joomla/form/fields/rules.php

but if me and others can avoid having to maintain such an override , it would be nice

Exactly what I said in #20007 (comment)

I don't know what kind of functionality that grouping logic provides (maybe none right now and it's just acting as a styling element in the form field to begin with), but introducing elements which will serve zero purpose in the ACL data schema to be able to adjust the rendering in the form field just seems wrong to me. Please remember that access.xml serves the ACL system and the Joomla\CMS\Access classes, the rule form field just introduces a UI to manage that data.

I agree with @mbabker

My initial idea was styling for ease of administrating but the access.xml has a larger purpose I wasn't considering. I think the suggested grouping by @mbabker is the correct way. Having groups could also allow nested groups which would work like the levels attribute.

Another simple idea would be to add a group attribute to the action field. The attribute should be ignored by everything but the form/field/rules.php and then in the config.xml we could specify the group labels and levels inside the field element.

example access.xml

<action name="core.create.store" group="store">
<action name="core.edit.store" group="store">

<action name="core.create.warehouse" group="warehouse">

<action name="core.create.stock" group="warehouse.stock">
<action name="core.edit.stock" group="warehouse.stock">

example config.xml

<field name="rules" type="rules">
    <group name="store" class="acl-store" label="COM_EXAMPLE_STORE" />
    <group name="warehouse" class="acl-warehouse" label="COM_EXAMPLE_WAREHOUSE">
        <group name="warehouse.stock" class="acl-warehouse acl-warehouse-stock" label="COM_EXAMPLE_WAREHOUSE_STOCK" />
    </group>
</field>

@venomDeved

I think that this PR is fully B/C

but yes i also like the groups better

My thoughts regarding the groups suggestion is about being B/C

• all extensions will continue to have the same XML since the existing format will continue to work and new format options will be optionally adapted
• the new format will only need to be recognized by the ACL management extensions which they will need to be updated to call new API methods

the new format will only need to be recognized by the ACL management extensions which they will need to be updated to call new API methods

There should not be a need for new PHP API methods. Pre- and Post- patch the existing methods should return the same data result with an existing XML definition and if we had a DTD to validate our XML schemas (we'll never have them, every time someone tries to create them they go to an abandonware repo) then that validation shouldn't be broken either.

Just because a method may be updated to return more data in new keys does not mean it is a B/C break. Otherwise adding a column to the database schema would be a B/C break, and we do that fairly frequently.

@mbabker is the additional group attribute and group element in the access/config manifest files a working solution?

I would be willing to try building this if it's considered worth trying.

There should not be a need for new PHP API methods

Yes if we only add a group attribute

Umm. No. Adding the structure exactly as I described in #20007 (comment) is not a B/C break.

• Old code would still be able to parse unchanged ACL definitions
• New code would still be able to parse unchanged ACL definitions
• Old code, if written correctly, should ignore new keys introduced and therefore not parse them
• New code, if updated correctly, should handle the new structure without issue

Otherwise, by your logic:

• Any data schema change in the database is a B/C break
• Any change in a model to introduce new data keys in a method fetching a list or single item is a B/C break (regardless of data schema change)
• Any change to any XML definition to introduce new tags is a B/C break

OK, so adding a group element to the access manifest won't break B/C. That will handle the grouping of the actions, I think we will still need the config field/group elements to style it on the HTML form.

@mbabker example access.xml

<section name="component">
    <action name="core.admin">
    <group name="store">
        <action name="core.admin.store" />
    </group>
</section>

example config.xml

<field name="rules" type="rules">
    <group name="store" class="acl-store" label="COM_EXAMPLE_STORE" />
</field>

The form field IMO is the easier of the two to figure out. The ACL XML has wider reach (because it can potentially affect the data storage and resolution of ACL actions) and that part of the system probably needs to be ironed out before making the UI adjustments in the form field.

Yeah, I see this as a long term fix, something maybe not released til v4 even. Is there a process to approve an xml structure or are we doing it right now?

Basically doing it right now, there's no formal process.

When i get some spare time i will open a new PR to do as suggested

<section name="component">
    <action name="core.admin">
    <group name="store">
        <action name="core.admin.store" />
    </group>
</section>

when i do new PR i will close this one

@venomDeved
or you can do it now / sooner if want

I don't have a lot of time to work on this, at the moment I've started with the phpunit tests and will work upwards from there. Basically I'm checking any code that opens access.xml

I'm happy to work on this together, can we PM?

Thanks anyone spending time on this PR
No interest in spending more on it by me