Do it! Do it!
Starsky & Hutch movie
After all of this defining and creating, we need to put some order in the house. In this chapter, we will create privileges and roles for the users that allow them to do only the required tasks. We will learn about the ACL system, how the permission system of eZ Publish works, and will create the groups and the roles needed by the site. Then, we will look at the workflow system and create a notification workflow for the site's blog.
When we work in a big company, everyone has his or her own role, tasks, and permissions. For example, an advertising guy will never touch a server, and a web designer will not write a contract. eZ Publish is like a big company, where the administrator can do everything, or can delegate specific tasks to users or group of users. This behavior is called ACL (Access Control List) and is based on roles, policies, and groups.
Moreover, as in any big company, eZ Publish needs to verify that its employee is who he claims to be, and needs to allow him to read the content that he can access.
Luckily, eZ Pubish has these features natively integrated into its core, as user account management.
A policy is an atomic right that allows a user to use a given functionality of a module, for example, to create a new blog post in the blog. A policy is based on three parts: a module name, the name of one of the functions of the module, and a permission on that function. If we think about the previous example (creating a new blog post in the blog), the policies allow a user to access the create function of content modules of the Blog post class object.
We have to remember that we can create a policy to use all of the functions of a particular module and that not all of the functions need to be limited. Moreover, the limitations may change from module to module.
When we put a bunch of policies together, we create a role. We can assign a role to either a single user or to a group of users. A role can also be limited to a particular section or navigation sub-tree. Using the policies example again, we can assign the policy to create a blog post to a role, and then assign this role to two groups. However, whereas the first group will create a blog post everywhere, the other group will be limited to a particular section of the site.
We can use three main strategies to apply a role to a group (or a user)—all of them with their pros and cons.
The first strategy is to create many atomic roles, all of them with specific policies. This solution allows us to create and manage small roles. But we have to add, for example, both the Anonymous and Editor roles to the Editor groups to allow them to read public content.
The second solution use with a different approach. The roles will have all of the policies required to fulfill a particular task. For example, the Editor role will also include all of the policies of the Anonymous role. In this case, if we change the policies of the Anonymous role, not all of the groups that have Editor role will be involved.
The third solution is to create groups with a very small subset of roles, and then add all of them directly to the users. This solution is optimal for managing specific users, but it is not recommended for a site that has a lot of users and groups.
Obviously, we can also merge and combine the three approaches, but we suggest to always keep it as simple as possible.
As the name suggests, a User group is a collection of users. eZ Publish represents user groups as specific nodes that contain user accounts. A user group can also contain another user group.
When we talk about users, we have to remember that they are also eZ Publish content objects that contain particular information regarding the user itself, which is provided by the User account datatype.