The Access Control Editor provides the option to control user access, e.g. for reading or modifying folders and documents and to give permission on access control settings on these. Please note that document permissions on folders are working recursively, thus if modify access to a folder is not permitted, none of the documents in this folder or sub-folders can be modified.
The Access Control Editor is opened via the Security Settings option in a Document context menu. Refer to section Setting Security of chapter Document Operations for details.
The editor contains the following two tables:

Figure: Access Control Editor
Note
To use security with Jackrabbit in the rapid application environment,
you have to enable security settings as described in the following section.
To make security work with Jackrabbit, perform the following steps:
carnot-jackrabbit/WEB-INF/jackrabbit:repository.xml, e.g. repository.xml.nonsecurerepository.xml.security to repository.xmlcarnot-jackrabbit/WEB-INF/config/ipp/spring:jackrabbit-jcr-context.xml, e.g. jackrabbit-jcr-context.xml.nonsecure.jackrabbit-jcr-context.xml.security to
jackrabbit-jcr-context.xml.
Figure: Replaced security files in RAD.
Please note that implicit policies are only set on folder creation
with the security enabled. In case you set the security after a folder
is already created from a non security enabled repository access,
the policy is not retroactively set. A user without administrator role
does not have access to this folder. In this case a user with administrator
role has to set policies on the folder manually.
For example to make it possible to upload documents, policies on the folder
/process-instances have to be set manually if it was created
before the security setting.
For the following folder pattern, the permission ALL
is set on creation for everyone in case security is enabled:
/ipp-repository/partitions/<partitionId>/process-instances/ipp-repository/partitions/<partitionId>/realms/<realmId>/users/<userId>/ipp-repository/partitions/<partitionId>/preferencesSince version 9.0.24.0, document centric access control evaluation is included in a newly created security Jackrabbit repository. In case access control has been set for files individually, access control is now evaluated separately without folder hierarchy inheritance.
If you like to use this feature, but you are using a
repository created with an earlier version, you need to configure the AccessControlProvider inside a
WorkspaceSecurity tag after the SearchIndex entry for each workspace.
In this case add the following workspace security section to the workspace template creation entry in your
repository.xml security file:
<Workspace name="${wsp.name}">
...
<!-- Search index and the file system it uses -->
<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
...
</SearchIndex>
...
<!-- Workspace Security -->
<WorkspaceSecurity>
<!-- Files with ACLs are evaluated separately without Folder hierarchy. -->
<AccessControlProvider class="org.apache.jackrabbit.core.security.authorization.acl.FileACLProvider" />
</WorkspaceSecurity>
Note that for existing repositories the same entry needs to be added in the workspace.xml
file, which resides in the according repository path, to become effective.
The following permissions are provided for participants:
: inherit permission for according action on folder/document
: allow according action on folder/document
: deny according action on folder/document
Documents and folders inherit permissions from their parent folders. Note that entries of inherited permissions are not editable in the table.
The following columns are listed for inherited permissions on folders:

Figure: Inherited Permissions for a folder.
The table columns to be displayed can be selected individually by clicking the
icon
to open the Select Columns dialog. This dialog is described in chapter
Selecting and Reordering Columns in Tables.
Per default, inherited permissions for Administrators
and Everyone are set. Administrators have the grant
Allow for all permissions. Everyone has an Allow value set for
the reading grant, whereas all other permissions for Everyone are Inherit
(indicated by three dashes) by default.
The following columns are listed for inherited permissions on documents:

Figure: Inherited Permissions for a document.
Note
Once you give a document individual permissions, the inherited permissions from
the parent folder are ignored!
Per default, inherited permissions for Administrators
and Everyone are set. Administrators have the grant
Allow for all permissions. Everyone has an Allow value set for
the reading grant, whereas all other permissions for Everyone are Inherit
(indicated by three dashes) by default.
Depending on whether the Access Control Editor was opened for a folder or for a document, one of the following tables are available:
The table columns to be displayed can be selected individually by clicking the
icon
to open the Select Columns dialog. This dialog is described in chapter
Selecting and Reordering Columns in Tables.
The following operations on permissions are provided:
Granted permissions on folders have a table with the following columns:

Figure: Granted Permissions on a Folder
Granted permissions on documents have a table with the following columns:

Figure: Granted Permissions on a Document
To add a participant to change the permission of, click the
Add Participants icon
in the toolbar.
The Select Participant dialog opens. The allowed participants are role, organization, department and its sub-organization and children.

Figure: Select a Participant
Select the participant in the table or click the link Pick from Tree. The participant tree gets displayed, where you can select the participant from.

Figure: Participant Tree
The selected participant is created in the table with editable permissions.

Figure: Participant added to table
Note that the access can be granted to a role but when the role is scoped, the accessing user's scope that is department is also displayed. So, if a user would not be allowed to see or work with a process instance due to department association then similarly, the access to the process attachment is denied to that user.
To remove selected participant(s) from the permissions table, you can either:

Figure: Removing a Participant via Remove action.
Selecting one or more participant(s) in the table is done by clicking directly on the according row(s). For details on selecting rows in tables, refer to chapter Selecting Rows in a Table. Note that administrators cannot be removed and will remain even in case all rows are selected.
To edit selected permission(s) you can do one of the following:

Figure: Edit a Permission

Figure: Editing all selected Permissions
Now the permissions for the participant(s) can be edited.

Figure: Permissions can be edited now.
You can switch the granted permissions in the columns between the following values provided in the drop-down list:

Figure: Set the Permission.
Click Apply to apply your changes.
Please refer to https://github.com/ajaxorg/ace/wiki/Default-Keyboard-Shortcuts for a an overview on provided keyboard shortcuts in the Access Control Editor.