Closed honstar closed 6 years ago
This is usually solved in the application leveraging the core wcm components, compare with we-retail which set's those rights with their "ui.content" package in https://github.com/Adobe-Marketing-Cloud/aem-sample-we-retail/blob/master/ui.content/src/main/content/jcr_root/conf/we-retail/settings/wcm/policies/_rep_policy.xml.
I'm fine with applying proper permissions on the consuming side. Is this documented anywhere that custom permissions need to be set in case page policies are used in editable templates?
This has been documented here: https://helpx.adobe.com/experience-manager/6-4/sites/developing/using/page-templates-editable.html#main-pars_title_1739798510
In case some information is still missing, please reopen.
Thanks for the update @gabrielwalt 👍
Bug Report
Current Behavior Given an editable template with a page policy set that points to one or more clientlib categories. A page based on that template renders fine with all expected CSS styles on the authoring instance.
However, once that page is replicated across to a publish instance and subsequently requested, the clientlibs defined via the template's page policy are not loaded, hence the design of the page is broken.
This is caused by lack of permissions to read both a page's
Template
andContentPolicyStyle
usinganonymous
on publish.Expected behavior/code All clientlibs should be loaded on publish instances as well via
anonymous
.Environment
Possible Solution To overcome permission issues while accessing a page's
Template
andContentPolicyStyle
objects, a separate service to read these could be added. That service would use a specific service user mapped against a system user that provides read access to the following:/conf/*/templates
/conf/*/policies
Alternatively, granting read access could theoretically be delegated to the consuming project. However, this would require explicit documentation and kind of goes against the OOTB functionality that the Core Components Page brings to the table.