Restrict user to publish the page from author instance

[bhagchand]

Hi Team,

Hope you are doing well.

Is there any access rule to restrict author user to publish the page. as currently all content authors are publish the page. 

Thanks

Bhagchand Saini

[Sady_Rifat]

Hello @bhagchand ,

You can simply remove the user "replicate" permission to restrict the author from page publication. 

http://localhost:4502/useradmin 

But for standard practice, you shouldn't do this by this way. 

For this you can create 2 separate user groups, say Base Author and Base Approval.

Base Approval will have all the permission that Base Author has additional replicate permission also. Now when you have the 2 separate user groups assign this group to the end users.
Let's say Mr. X is a member of Base Author and Mr. Y is a member of Base Author and Base Approval. 

Since Mr. X is not a member of Base Approval he has no permission of replication and is unable to publish a page.

If you think still it's complicated there is a tool to manage it by writing code.

Check this Access Control Tool: https://github.com/Netcentric/accesscontroltool 

[bhagchand]

Thanks @Sady_Rifat , let me check

[ShaileshBassi]

Hi @bhagchand For providing the permissions it is always recommended to create the repoinit file, so that it can promoted to the higher environment and there is no chance of the human errors over there.

Below is a sample Repo Init OSGi configuration with jcr:primaryType “sling:OsgiConfig”:

/apps/myproject/config/org.apache.sling.jcr.repoinit.RepositoryInitializer-demo.xml

scripts = “[

create group demo-group,

create path (sling:OrderedFolder) /content/dam/project

set ACL for demo-group

deny crx:replicate on /content/dam/project;

end

]”

Above is an example for explicitly deny the publishing permission, but it also be that from starting only the permissions are provided for the paths where publishing is required.

Hope this helps!

Thanks

[markus_bulla_adobe · Accepted solution]

Hi @bhagchand!

As mentioned by @Sady_Rifat and @ShaileshBassi already, there are dedicated Access Control Lists (ACLs) available for replication. Please refer to the documentation around User Administration [1] and check for the "Replicate" action.

In general, ACLs can be managed through the authoring UI. However, as outlined by @ShaileshBassi it is usually a better idea to manage your groups and their according permissions through code, e. g. as RepoInit [2] scripts or dedicated tools, such as the Netcentric AC Tool [3].

In addition to that, please make sure to manage your ACLs on a group level and avoid assigning permissions to single users (emphasizing/clearing on what @Sady_Rifats wrote). My recommendation is to start with the OOTB groups [4] that are available within AEM as a starting point and base project-specific groups on these through inheritance by building a hierarchy of group memberships.

Doing so, it is important to only deny on the initial level of your hierarchy (deny as much as possible without breaking anything with regards to general system functionality for the users). Starting from there, more specific groups should allow what ever is required for their respective business use cases. Avoid denying ACLs on deeper levels of the group hierarchy as this will make things much more complex and you might end up with unexpected results (although I admit that it's not 100% avoidable for certain, rare cases).

Hope that helps!

[1] https://experienceleague.adobe.com/docs/experience-manager-65/administering/security/security.html#a...

[2] https://sling.apache.org/documentation/bundles/repository-initialization.html

[3] https://github.com/Netcentric/accesscontroltool

[4] https://experienceleague.adobe.com/docs/experience-manager-65/administering/security/security.html?l...