ACL for touch UI content authoring

[vivs92490136]

What is the ACL settings required for a content author to edit content in touch UI. Is it different from classic UI? We created a user and provided read only access to "apps","bin","etc" and "libs". Read,modify and delete access for "content". When we try authoring content in classic UI with this user, it is working fine. However when we try authoring content in touch UI, we get null pointer exception in various files in com.granite.ui. Whereas for an admin user content authoring works fine in touch UI. Is this an issue with the ACL settings for the user? Do we need to provide access to any specific folder for touch UI authoring? 

[Abhishek_Dweved · Accepted solution]

I think adding user to group contributor or author should get appropriate permissions for content authoring.

Best Regards,

Abhishek Dwevedi

[kautuk_sahni]

Hi ,

Please have a look at this documnetation:

Link:- https://docs.adobe.com/docs/en/aem/6-2/administer/security/security.html

// Here in this documentation you would get to know the basic groups and their functionality.

So, as mentioned by Abhishek, content-authors or contributor would work for you.

                                                                         

User ID	Type	Description	Recommendation
admin Default password: admin	User	System administration account and member of the administrator group, with full access rights. This account is used for the connection between AEM WCM and CRX. If you accidentally delete this account, it will be re-created upon repository restart (in the default setup). The admin account is a requirement of the AEM platform. As a consequence, this account cannot be deleted.	Adobe strongly recommends that the password for this user account be changed from the default. Preferably upon installation, though it can be done afterwards. Note: This account is not to be confused with the admin account of the CQ Servlet Engine.
anonymous	User	Holds the default rights for unauthenticated access to an instance. Per default this holds the minimum access rights. If you accidentally delete this account, it will be re-created upon startup. It cannot be permanently deleted, but it can be disabled.	Modifying this account has additional security implications. If you have to edit this account, make a backup copy first.
author Default password: author	User	A author account allowed to write to /content. Encompasses contributor and surfer privileges. Can be used as a webmaster as it has access to the entire /content tree. This is not a built-in user, but another geometrixx demo user	Adobe recommends that either the account is deleted completely, or the password changed from the default. Preferably upon installation, though it can be done afterwards.
administrators	Group	Group that gives administrator rights to all its members. Only admin is allowed to edit this group. Has full access rights.	If you set a 'deny-everyone' on a node, the administrators will only have access if it is enabled again for that group.
content-authors	Group	Group responsible for content editing. Requires read, modify, create and delete permissions.	You can create your own content-author group(s) with project specific access rights, provided you add read, modify, create and delete permissions.
contributor	Group	Basic privileges which allow the user to write content (as in functionality only). Does not allocate any privileges to the /content tree - these must be specifically allocated for the individual groups or users.
everyone	Group	Every user in AEM is a member of the group everyone, even though you may not see the group or the membership relation in all tools. This group can be thought of as the default rights as it can be used to apply permissions for everyone, even users that will be created in the future.	Do not modify or delete this group. Modifying this account has additional security implications.
tag-administrators	Group	Group that is allowed to edit tags.
user-administrators	Group	Authorizes user administration, that is, the right to create users and groups.
workflow-editors	Group	Group that is allowed to create and modify workflow models.
workflow-users	Group	A user participating in a workflow must be member of group workflow-users. This gives him or her full access to: /etc/workflow/instances so that he or she can update the workflow instance. The group is included in the standard installation, but you must manually add your users to the group.

~kautuk

[vivs92490136]

Sorry for the delayed response. Adding user to group contributor did not fix the issue. We could not add the user to the group author as the group has modify access to entire content repository. The user we had was supposed to have access only to his/her division and not the entire content repository. The root cause of the issue was not providing read access to "/etc/cloudservices/scene7". Somehow for touch UI authoring to work properly, the user needs read access to "/etc/cloudservices/scene7". Even in the author group this access is specifically enabled and that is the reason adding the user to author group fixes the issue.