A new User does not have permissions for any part of the system, unless they are explicitly given access. To get access they need to inherit Roles, typically assigned to the User Group they belong to.
Each Role can contain one or more Policies. A Policy is a rule that gives access to a single function in a module.
For example, a
section/assign Policy allows the User to assign content to Sections.
When you add a Policy to a Role, you can also restrict it using one or more Limitations.
A Policy with a Limitation will only apply when the condition in the Limitation is fulfilled.
For example, a
content/publish Policy with a
ContentType Limitation on the "Blog Post" Content Type will allow the User to publish only Blog Posts, and not other Content.
A Limitation, like a Policy, specifies what a User can do, not what they can't do.
Section Limitation, for example, gives the User access to the selected Section, not prohibits it.
See Available Limitations for further information.
Policies on one Role are connected with the and relation, not or, so when Policy has more than one Limitation, all of them have to apply.
If you want 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.
Assigning Roles to Users¶
Every User or User Group can have many roles. A User can also belong to many groups, for example, Administrators, Editors, Subscribers.
It is best practice to avoid assigning Roles to users directly. Instead, try to organize your content so that it can be covered with general roles assigned to User Groups.
Using Groups is easier to manage and more secure. It also improves system performance. The more Role assignments and complex Policies you add for a given User, the more complex the search/load queries will be, because they always take permissions into account.
Here are a few examples of sets of Policies you can use to get some common permission configurations.
Enter back end interface¶
To allow the User to enter the Back Office interface and view all content, you need to set the following Policies:
These Policies will be necessary for all other cases below that require access to the content structure.
Create and publish content¶
To create and publish content, the user 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!).
Create content without publishing¶
This option can be used together with eZ Enterprise's content review options. Using the following Policies, the User is able to create content, but can't publish it; instead, they must send it for review to another User with proper permissions (for example, senior editor, proofreader, etc.).
Note that without eZ Enterprise this setup should not be used, as it will not allow the User to continue working with their content.
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, you need to use Limitations.
Three Limitations that could be used 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
Subtree of Location Limitation on the Blog Content item.
This will allow the User to publish content anywhere under this Location in the structure.
Section Limitation can be used similarly, but a 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 will be able to publish content directly under the selected Location, but not anywhere deeper in its Subtree of Location.
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 using Limitations on the
A Location Limitation limits 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
which only allows Content items of type Image. This ensures that only files of type
image can be uploaded,
and only to the Pictures Folder.
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, you need to grant them the following Policies:
Hiding and revealing Location requires one more Policy:
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,
e.g. because it belonged to a Section they do not have permissions for.
To allow anonymous users to register through the
/register route, you need to 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 will allow 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 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".
||grant all available permissions|
||view the content both in front and back end|
||view content embedded in another Content item (even when the User is not allowed to view it as an individual Content item)|
||create new content. Note: even without this Policy the User is able to enter edit mode, but cannot finalize work with the Content item.|
||edit existing content|
||publish content. Without this Policy, the User can only save drafts or send them for review (in eZ Enterprise)|
||remove Locations and send content to Trash|
||hide and reveal content Locations|
||see all content that a Content item relates to (even when the User is not allowed to view it as an individual Content items)|
||remove Locations and send content to Trash|
||view content after publishing, and to preview any content in the Page mode|
||remove archived content versions|
||manage the language list in Admin|
||manage URL aliases of a Content item|
||restore content from Trash|
||empty the trash (even when the User does not have access to individual Content items)|
||modify existing Content Types. Also required to create new Content Types|
||create new Content Types. Also required to edit exiting Content Types|
||delete Content Types|
||assign Object States to Content items|
||view, add and edit Object States|
||assign roles to Users and User Groups|
||modify existing Roles|
||create new Roles|
||view the Roles list in Admin. Required for all other role-related Policies|
||assign Sections to content|
||edit existing Sections and create new ones|
||view the Sections list in Admin. Required for all other section-related Policies|
||view the System information tab in Admin|
||log in to the application|
||access and set user preferences|
||register using the
||change stage in the specified workflow|
Permissions for custom controllers¶
You can control access to a custom controller by implementing the
In the following example the user does not have access to the controller unless they have the
1 2 3 4 5 6 7
Attribute accepts three arguments:
moduleis the Policy module (e.g.
functionis the function inside the module (e.g.
limitationsare optional limitations to check against. Here you can provide two keys:
valueObjectis the object you want to check for, for example
targetsare a table of value objects that are the target of the operation. For example, to check if Content can be assigned to a Section, provide the Section as
targetsaccept Location, Object State and Section objects.
Checking user access¶
To check if a user has access to an operation, use the
For example, to check if Content can be assigned to a section:
1 2 3
You can also use the permission resolver (
canUser() method checks if the user can perform a given action with the selected object.
canUser('content', 'edit', $content, $location );
content/edit permission for the provided Content item at the provided Location.
Blocking access to controller action¶
To block access to a specific action of the controller, add the following to the action's definition: