Motive : One day or another, you come across a use case where you want to have :
the processing logic for a template on one hand,
and the access rights to pages using this template on the other hand,
just like, on regular file systems, when your access rights to the various files (documents) may only depend on the document itself (its contents, not its type)
So for example, one may want to have :
vendorA users allowed to edit "product" template page pageProductA, but not pageProductB.
vendorB users allowed to edit "product" template page pageProductB, but not pageProductA.
Expressed in terms of API, this would be :
// "roleVendorA" role has been previoulsy created
// assignment of this role to the relevant users has been previously set
// same for "roleVendorB"
// then,
$pageProductA = new Page();
$pageProductA->template = "product";
$pageProductB = new Page();
$pageProductB->template = "product";
...
$pageProductA->addPermissionByRole("page-edit", "roleVendorA"); // equivalent of role assignment to template, but assigned to individual page
$pageProductA->save();
$pageProductB->addPermissionByRole("page-edit", "roleVendorB"); //
$pageProductB->save();
Or, expressed "in the style of UserGroups module", which doesn't use the native roles but its own dedicated groups
(but as of today in my understanding this can't be set via API, only via GUI) :
// "groupVendorA" UserGroup has been previoulsy created
// assignment of users to this UserGroup has been previously set
// same for "groupVendorB"
// then,
$pageProductA = new Page();
$pageProductA->template = "product";
$pageProductB = new Page();
$pageProductB->template = "product";
...
$pageProductA->addPermissionByGroup("page-edit", "groupVendorA");
$pageProductA->save();
$pageProductB->addPermissionByGroup("page-edit", "groupVendorB");
$pageProductB->save();
The expected result :
the permissions set at page level are overriding the permissions set at template or field level, via usage of page->addPermissionByRole and page->revokePermissionByRole
vendorA users have edit access on pageProductA, but not on pageProductB (except if this is allowed at template or field level)
vendorB users have edit access on pageProductB, but not on pageProductA (except if this is allowed at template or field level)
Why would the enhancement be useful to users?
The UserGroups module provides this capability (yet without the API side of things).
But it would feel more "safe & natural" that this capability is provided by the core.
Short description of the enhancement
Is it time to add "page-level access control" to the Processwire access control system ?
This topic was discussed several years ago, https://processwire.com/talk/topic/371-page-specific-permissions/ , and this led to the community-developped module UserGroups : https://github.com/apeisa/UserGroups , https://processwire.com/talk/topic/5658-alpha-release-usergroups-page-based-permissions/page/1/
Steps that explain the enhancement
Motive : One day or another, you come across a use case where you want to have :
So for example, one may want to have :
Expressed in terms of API, this would be :
Or, expressed "in the style of UserGroups module", which doesn't use the native roles but its own dedicated groups (but as of today in my understanding this can't be set via API, only via GUI) :
The expected result :
Why would the enhancement be useful to users?
The UserGroups module provides this capability (yet without the API side of things). But it would feel more "safe & natural" that this capability is provided by the core.