For AI agents: the complete documentation index is available at llms.txt; this page is also available as Markdown at index.md.

• Documentation >
• Permissions >
• Permission use cases

Permission use cases

Here are a few examples of sets of policies that you can use to get some common permission configurations.

Enter back office

To allow the user to enter the back office interface and view all content, set the following policies:

• user/login
• content/read
• content/versionread
• section/view
• content/reverserelatedlist

These policies are necessary for all other cases below that require access to the content structure.

Create content without publishing

You can use this option together with Cohesivo's content review options. Users assigned with these policies can create content, but cannot publish it. To publish, they must send the content for review to another User with proper permissions (for example, senior editor or proofreader).

• content/create
• content/edit

Create and publish content

To create and publish content, users must additionally have the following policies:

• content/create
• content/edit
• content/publish

This also lets the user copy and move content, and add new locations to a content item (but not remove them).

Move content

To move a content item or a subtree to another location, the user must have the following policies:

• content/read - on the source location
• content/create - on the target location

Remove content

To send content to Trash, the user needs to have the content/remove policy. If content has more than one language, the user must have access to all the languages. That is, the content/remove policy must have either no limitation, or a limitation for all languages of the content item.

To remove an archived version of content, the user must have the content/versionremove policy.

Further manipulation of Trash requires the content/restore policy to restore items from Trash, and content/cleantrash to completely delete all content from the Trash.

Caution

With the content/cleantrash policy, the user can empty the Trash even if they don't have access to the trashed content, for example, because it belonged to a Section that the user doesn't have permissions for.

Restrict editing to part of the tree

If you want to let the User create or edit content, but only in one part of the content tree, use limitations. Three limitations that you could use here are Section limitation, Location limitation and Subtree of Location limitation.

Section limitation

Let's assume you have two Folders under your Home: Blog and Articles. You can let a user create content for the blogs, but not in Articles, by adding a Section limitation to the Blog content item. This allows the User to publish content anywhere under this location in the structure. Section doesn't have to belong to the same subtree of location in the content structure, any locations can be assigned to it.

Location limitation

If you add a Location limitation and point to the same location, the user is able to publish content directly under the selected location, but not anywhere deeper in its subtree of location.

Subtree of location limitation

To limit the user's access to a subtree, use the Subtree of Location limitation. You do it by creating two new roles for a user group:

1. Role with a Subtree limitation for the User
2. Role with a Location limitation for the subtree

Follow the example below to learn how to do that.

Cookbook, Dinner recipes and Dessert recipes containers aren't accessible in the frontend. Edit access to them in the Admin panel.

To give the vegetarian editors access only to the Vegetarian dinner recipes section, create a new role, for example, EditorVeg. Next, add to it a content/read policy with the Subtree limitation for Cookbook/Dinner recipes/Vegetarian. Assign the role to the vegetarian editors user group. It allows users from that group to access the Vegetarian container but not Cookbook and Dinner recipes.

To give users access to Cookbook and Dinner recipes containers, create a new role, for example, EditorVegAccess. Next, add to it a content/read policy with the Location limitations Cookbook and Dinner recipes. Assign the new role to the vegetarian editors user group as well. Only then the limitations are combined with AND, resulting in an empty set.

The vegetarian editors should now see the following content tree:

When a policy has more than one limitation, all of them have to apply, or the policy doesn't work. For example, a Location limitation on location 1/2 and Subtree of Location limitation on 1/2/55 cannot work together, because no location can satisfy both those requirements at the same time. To combine more than one limitation with the or relation, not and, you can split your policy in two, each with one of these limitations.

Manage locations

To add a new location to a content item, the policies required for publishing content are enough. To allow the user to remove a location, grant them the following policies:

• content/remove
• content/manage_locations

Hiding and revealing location requires one more policy: content/hide.

Editorial workflows

You can control which stages in an editorial workflow the user can work with.

Do this by adding the WorkflowStageLimitation to content policies such as content/edit or content/publish.

You can also control which transitions the user can pass content through. Do this by using the workflow/change_stage policy together with the WorkflowTransitionLimitation.

For example, to enable the user to edit only content in the "Design" stage and to pass it after creating design to the "Proofread stage", use following permissions:

• content/edit with WorkflowStageLimitation set to "Design".
• workflow/change_stage with WorkflowTransitionLimitation set to to_proofreading

Multi-file upload

Creating content through multi-file upload is treated in the same way as regular creation. To enable upload, you need you set the following permissions:

• content/create
• content/read
• content/publish

You can control what content items can be uploaded and where by using imitations on the content/create and content/publish policies.

A location limitation limits the uploading to a specific location in the tree. A content type limitation controls the content types that are allowed. For example, you can set the location limitation on a Pictures Folder, and add a content type limitation that only allows content items of type Image. This ensures that only files of type image can be uploaded, and only to the Pictures Folder.

Taxonomies

You can control which users or user groups can work with taxonomies. To let users create and assign taxonomy entries, set the following permissions:

• taxonomy/assign to allow user to tag and untag content
• taxonomy/read to see the Taxonomy interface
• taxonomy/manage to create, edit and delete tags

With limitations, you can configure whether permissions apply to Tags, product categories, or both.

Register users

To allow anonymous users to register through the /register route, grant the user/register policy to the Anonymous user group.

Admin

To access the administration panel in the back office, the User must have the setup/administrate policy. This allows the User to view the languages and content types.

Additional policies are needed for each section of the Admin.

System Information

• setup/system_info to view the System Information tab

Sections

• section/view to see and access the section list
• section/edit to add and edit sections
• section/assign to assign sections to content

Languages

• content/translations to add and edit languages

Content types/action

• content type/create, content type/update, content type/delete to add, modify and remove content types

Object states

• state/administrate to view a list of object states, add and edit them
• state/assign to assign Objects states to content

Roles

• role/read to view the list of roles in Admin
• role/create, role/update, role/assign and role/delete to manage roles

Users

• content/view to view the list of users

Users are treated like other content, so to create and modify them, the user needs to have the same permissions as for managing other content items.

Product catalog

You can control to what extend users can access the product catalog and all its related parts.

Product type

To create or edit product types, a user needs to have access to attributes and attribute groups. Set the following permissions to allow such access:

• product_type/create
• product_type/view
• product_type/edit

Product item

When a product is created, a product item and a content item are also generated. Permissions for the product catalog override permissions for content, therefore, users without permissions for content can still manage products.

• product/create
• product/view
• product/edit

Copy as Markdown View as Markdown View on GitHub