We would like to request an enhancement that allows Site Initializer client extensions to declaratively set permissions at the individual asset level for all common content and folder types — web content articles, web content (journal) folders, documents, Documents & Media folders.
Currently this capability is inconsistent across asset types: some are fully supported while others are aren’t. This forces teams to fall back on custom Java or post-deployment scripting for what should be simple declarative configuration, undermining Site Initializers as a reproducible provisioning mechanism.
Current Behaviour:
Site Initializers CX apply permissions through two mechanisms: an inline permissions array on an asset’s own JSON, and a top-level resource-permissions.json file that grants a role a set of actions on a resource at a given scope (company, group, or individual). Individual-scope grants require the target asset’s generated primary key.
In practice, Documents / files (DLFileEntry) can be permissioned individually via resource-permissions.json (“primKey”: “[$DOCUMENT_FILE_ENTRY_ID:/path-to-asset-in-site-initialiser$]”) but web content articles, web content folders, DLFolders cannot be permissioned as the Placeholder do not exist for the primary key for these assets .
Desired Behaviour:
Similar to Documents / files (DLFileEntry), add support to other assets to allow individual-scoped permission through resource-permissions.json in Site-intiliaser CX.