The “parent” description will be changed eventually. I did think of both solutions, e.g. whether the parent should inherit conditions from its children or a child should inherit conditions from its parent.
I chose the latter thinking that the “parent” relationship is actually an “extend” relationship. Also, I thought, from a design perspective, a child (access level) should not be aware of any dependencies to it. I.e. a Silver access level should not be aware that it is lower than Gold, but rather Gold should be aware of (extend) Silver.
In the overview, UX wise, I know that one would initially expect Gold to “be above” its dependencies.
In your case though, it would make sense to do it the other way around.
Create access levels for Page_A and Page_B and add the right conditions to them.
Then, create an access level Editor_A that extends Page_A and an access level Admin_A that extends Editor_A. Do the same thing for Page_B.
Of course this creates two extra access levels than needed, but let me know if it works.
The “order” setting is used (as last resort) when checking for user access to some content, but it will eventually be removed from the UI.
Thread Starter
eric3d
(@eric3d)
Thanks Joachim,
I ended up ignoring the parenting altogether and created 3 access levels:
– View_page_A (target= page_A, synced with Usergroup_A)
– View_page_B (target= page_B, synced with Usergroup_B)
– View_all (target= page_A, page_B, not synced)
Then I used the Access level to grant View_all access to admin, editors and authors (there aren’t too many of them)
While it may confuse users, it may be nice to have a “synced and manual” mode that would, for example, sync View_page_A with Usergroup_A, but still allow me to grant that permission manually to the admins. In that case, change the Access level on the profile page to checkboxes so I can select both View_page_A and View_page_B.
