Repoinit Script for creating system user with jcr:all giving runtime deployment error

[NageshRaja]

Hi All,

I am new to repoinit so trying to create a system user with below path access - 
/content/dam/myapp/folderA

/content/myApp/en/services/folderA

I want to have jcr:all access for both these paths to keep it as simple as possible.

Here's my script - 

"create service user Test with path system/myApp",
"ensure nodes (sling:Folder) /conf",
"ensure nodes (sling:Folder) /content/dam/myApp/folderA",
"ensure nodes (sling:Folder) /content/myApp/en/services/folderA",
"set ACL for Test\n allow jcr:read on /conf\n allow jcr:all on /content/dam/myApp/folderA\n allow jcr:all on /content/myApp/en/services/folderA\nend"
]

I also have defined as cq:Page in .content.xml for ui.content module for pages - myApp, en, services, folderA
However, the cloud manager stops deployment at stage installing mutable content.

1. If I don't use ensure nodes then the deployment fails at runtime with error javax.jcr.RepositoryException: Failed to set ACL (javax.jcr.PathNotFoundException: Cannot set ACL on non-existent path)

This is understandable as the repoinit runs before ui.content module might be deployed.

2. If I use sling:Folder as ensure nodes for /content based cq:Page paths then also the deployment fails

Ideally this should have worked as the reasoning was that repoinit will create sling:Folder for each node at path /content/myApp/en/services/folderA and then ui.content which has .content.xml defined for each node will update the jcr:primaryType to cq:Page

Apparently that also does not work since the filter definition for "/content/myApp" is set to mode "merge" so if repoinit runs first then that definition stays.

3. I upgraded the ensure nodes for /content/myApp/en/services/folderA to below - 

"ensure nodes (sling:Folder) /content/myApp(cq:Page)/en(cq:Page)/services(cq:Page)/folderA(cq:Page)",

The idea was that repoinit will create cq:Page node and then .content.xml will add jcr:content with type cq:PageContent to the nodes created by repoinit.

This approach works from deployment point of view but when I check the nodes then no jcr:content is present on these.

However, the folderA now has rep:policy node with allow node further tagged to the system user.

I am not sure though why this time with mode merge in place the updated properties from ui.content.

To check if the ui.content was working correctly I reinstalled the package. This time the updated jcr:content reflected in folderA but the rep:policy node disappeared as expected.

So I am having trouble aligning these 2 aspects of repoinit script and ui.content's configuration for the page node.

I am not sure if the problem is as hard as I am finding it to be. Can anyone please help with this?

@arunpatidar, @SantoshSai, @BrianKasingli, @Rohan_Garg, @daniel-strmecki 

daniel-strmecki

Thanks,

Nagesh

[SantoshSai]

Hi @NageshRaja,

Seems like RepoInit executes before ui.content

• RepoInit scripts run during the provisioning of the OSGi container, before your content packages (like ui.content) are installed.

• That means your /content/myApp/... nodes don’t exist yet when RepoInit tries to set ACLs -> hence the PathNotFoundException.

I would Split ACL setup into a separate content package

This is the cleanest, Cloud-safe way.

• Create your system user and ACL setup in a separate content package that depends on your content structure being present.

• You can ensure the order via dependencies in your pom.xml:

  <dependency>
      <groupId>com.myapp</groupId>
      <artifactId>myapp.ui.content</artifactId>
      <version>${project.version}</version>
  </dependency>

• Then your RepoInit can safely assume that /content/myApp/... exists.

RepoInit (in ui.config)

create service user Test with path system/myApp
set ACL for Test
  allow jcr:read on /conf
  allow jcr:all on /content/dam/myApp/folderA
  allow jcr:all on /content/myApp/en/services/folderA
end

This case, No need for ensure nodes since ui.content ensures page structure exists.

[NageshRaja]

Hey @SantoshSai, do we have any documentation or blog link which follows the same?

I actually have multiple repoinit users each tied to some different functionality.

[Rohan_Garg]

Hey @NageshRaja, You might want to read up on a couple of blogs here - 

1.  @Jörg_Hoh has written a great blog on this How to deal with RepoInit failures in Cloud Service

2. https://aemslate.com/aem-cloud-system-service-user-guide

If you check #1 and try the below points from it - 

It is hard to validate this locally, as you don’t have an immutable /apps and /libs, but there is a test approach which comes very close to it:

• Run all your repoinit statements in your local test environment
• Install all your content packages
• Enable write tracing (see my blog post)
• Re-run all your repo-init statements.
• Disable write tracing again

Also @SantoshSai has good suggestion of putting this in a separate content package and have it dependent on your ui.content to ensure the scripts are executed later.

Best Regards,

Rohan Garg

[NageshRaja]

thanks - will try this 👍