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:
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 Ibexa Experience'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, proofreader, etc.).
Use this setup with Ibexa Experience or Ibexa Commerce only, as Ibexa Content does not allow the User to continue working with their content.
Create and publish content¶
To create and publish content, users must additionally have the following Policies:
This also lets the user copy and move content, as well as add new Locations to a Content item (but not remove them).
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
To send content to Trash, the User needs to have the
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
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.
content/cleantrash Policy, the User can empty the Trash even if they do not have access to the trashed content,
for example, because it belonged to a Section that the User does not 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
Location Limitation and
Subtree of Location 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 does not have to belong to the same Subtree of Location in the content structure, any Locations can be assigned to it.
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:
- Role with a
SubtreeLimitation for the User
- Role with a
LocationLimitation for the Subtree
Follow the example below to learn how to do that.
Cookbook, Dinner recipes and Dessert recipes containers are not 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
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 does not work.
For example, a
Location Limitation on Location
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.
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:
Hiding and revealing Location requires one more Policy:
You can control which stages in an editorial workflow the user can work with.
Do this by adding the
content Policies such as
You can also control which transitions the user can pass content through.
Do this by using the
workflow/change_stage Policy together with the
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:
WorkflowStageLimitationset to "Design".
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:
You can control what Content items can be uploaded and where by using Limitations
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.
You can control which users or user groups can work with taxonomies. To let users create and assign taxonomy entries, set the following permissions:
assign- to allow user to tag and untag content
read- to see the Taxonomy interface
manage- to create, edit and delete tags
With Limitations you can configure whether permissions apply to Tags, Product categories or both.
To allow anonymous users to register through the
/register route, grant the
user/register Policy to the Anonymous User Group.
To access the administration panel in the Back Office, the User must have the
This allows the User to view the languages and Content Types.
Additional Policies are needed for each section of the Admin.
setup/system_infoto view the System Information tab
section/viewto see and access the Section list
section/editto add and edit Sections
section/assignto assign Sections to content
content/translationsto add and edit languages
Content Type/deleteto add, modify and remove Content Types
state/administrateto view a list of Object states, add and edit them
state/assignto assign Objects states to Content
role/readto view the list of Roles in Admin
role/deleteto manage Roles
content/viewto 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.
You can control to what extend users can access the Product catalog and all its related parts.
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:
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.
To control which commerce functionalities are available to store users, you can grant or prevent them access to individual components.
A minimal use case would be defining the following store user Roles: Visitor and Registered buyer.
You can use the Visitor Role to prevent anonymous users from being able
to purchase products.
You can do this by granting
catalog/view permissions only.
The Registered buyer Role can then be used to allow users who have logged in to view products, see product prices, add products to a cart and proceed with the checkout process. You do this by granting this Role the following set of permissions:
user/login, to control access to registration and login
catalog/view, to allow viewing a product list and product details
cart/edit, to allow adding items to a shopping cart and modifying cart contents, for example, by removing items
checkout/delete, to allow proceeding to checkout and interacting with the checkout process
See below for a detailed listing of permissions that apply to Commerce, together with their meaning,
Set the following permissions to decide what actions are available when users interact with carts:
cart/view- to allow user to view their cart
cart/delete- to delete cart, for example, after successful checkout
cart/create- to create a new cart
cart/edit- to allow user to add products to their cart
To further control the access to a cart, you can use the
and set its value to
This way users can only interact with their own carts.
Set the following permissions to decide what actions are available when users interact with checkout:
checkout/view- to control user access to checkout
checkout/create- to allow starting the checkout process, by proceeding from cart
checkout/update- to allow users to modify existing information, for example item quantity
checkout/delete- to delete checkout