This tutorial explains how to create security rules into ERP5. This is important in ERP systems since you might not want everyone to be able to perform all actions into the system. In our example we will define three roles, the administrator of the forum, the user and the visitors.
The forum is functional so far, but only the site administrators can use it properly. You will now learn how to configure the security for your application.
It's important that you understand how security is modelled in ERP5 models, as such you should read these documentation items before proceeding:
ERP5 5A Security Model
How to Design Security
Security is usually modelled in terms of "who" can "do what" under which "circumstances". From
the explanation of the workflow states we created before, three kinds of
"actors" or "functions"
(as we will configure later) are going to interact with the Forum:
forum Visitor, who can read public threads and their posts.
forum Editor or User
, who can create new threads, edit them, post replies to them and make
forum Administrator, which is not necessarily a site administrator, and is responsible for
moderating the threads: closing them for comments or making them private or sticky.
In ERP5, when creating new "functions" to be performed by users in a new application, these functions are usually implemented through Categories in the Base Category called Function.
To create them, select Configure Categories in the My Favorites menu. Then look for the Function Base Category. If you can't see it at first, it might be in one of the following pages.
You can also search for it by typing Function in the Title field or function in the ID field in the line with the “cog wheel”, then clicking that wheel.
Once inside the Function Base Category, select Add Category in the Action menu, then fill in at least the following properties for your new Category:
Description: Function Category for forum users
Don't forget to save your changes.
From this newly created Function category, subcategories can be created that represent the actual functions of users in the Forum application.
In the page of Forum category, select Add Category in the Action menu to create our Forum Administrator function. Fill in the fields with these values:
Description: Forum Administrator
Go back to the Forum category to add two other subcategories:
● Id: user
● Title: User
● Codification: USR
● Description: Forum User that can create new threads
Be careful to add the above categories to the Forum category only. At the end, going back to the Forum category you should see your newly created Forum functions as in the illustration above.
Now we have created functions for Forum module, we can now create Person objects from Person module, and configure them to access the site.
Go to Main Page >> Persons and select Add Person in the Action menu.
In the View tab, fill in the First and Last names of the person you just added.
Then in the Assignment tab, make sure that the user has credentials for logging into the site by filling in the fields for login, password and password confirmation.
After set login and password, you must validate the person and start his assignment. Otherwise, for the final tests, it will be impossible for us to connect with his login/ password.
To validate, go to the
Action bar and select Validate.
In next slide, we will assign function to the user, then start the assignment.
After validating the new Person, we have to assign a forum function to him.
While looking at the Person object, select Add Assignment from the Action menu. Then
Forum/Administrator value for the Function field, and type in a title for this assignment. Also, you must settle a period for the assignment.
After you save the form, select Start Assignment from the Action menu. You should then see the State field of this assignment should read Started.
Repeat the steps on the previous slide and this one to create two more Persons assigning respectively each of the other two Function categories: Forum/User and Forum/Visitor. If you want, you can create even more Person objects with these assignments.
Once the function categories have been defined, they need to be mapped to actual roles on the objects. This is done with role mapping rules defined centrally in the Portal Types of objects.
The Role mapping infrastructure of Portal Types in ERP5 enables arbitrarily complex rules to be applied when mapping categories to the "5A" roles of the ERP5 security infrastructure. In this tutorial, the security mapping rules of the erp5_dms Business Template provide for a simple mapping of category functions to security roles.
Go to Portal Types >> Discussion Thread Module and click on the Action tab select
. Then fill the form with the following information:
Description: Forum Administrators and Users are allowed to access the module and create threads.
This maps the
Author and Auditor roles to the Administrator and User function categories.
Repeat the previous step and add the Visitor category.
Description: Forum Visitors can view the discussion thread module and the public threads inside it.
Don't forget to click on "Update Local Roles" back in Action menu in Discussion Thread Module after you've added all the role mappings.
Besides setting up role mapping on the Discussion Thread Module, we also need to set up role mapping on the Discussion Thread objects themselves.
Navigate to Portal Types >> Discussion Thread and click on the Action tab select "Add Role Information". Then fill the form with the following information:
Description: Forum Administrators are allowed to modify any thread and change its status.
Use the same form to add role mapping for the User category in thread:
● Title: User
Description: Forum users can reply to thread posts.
For the last role mapping on Discussion Thread, Visitors need to be able to read the threads, even if they can't do anything else. So add the following role mapping to Discussion Thread as well:
● Name: Visitor
Description: Forum visitors read threads with their posts.
If you have existing Threads and don't intend to delete them, don't forget to click on "Update Local Roles" on this portal type as well to synchronize the role mapping on those instances after you've added all the role mappings.
We could also add role mappings for the Discussion Post portal type, but since it is basically an embedded object into discussion threads and it is not manipulated individually, it can inherit the role mappings of its container, which will be a Discussion Thread.
Navigate back to Portal Types >> Discussion Post. Then enable the "Acquire Local Roles" checkbox present in Properties.
Don't forget to click on "Update Local Roles" afterwards.
Since the discussion forum displays information on the Persons that posted threads or replies, we need to enable access for the Person objects to the users of the Discussion Forum. And since Person objects are contained inside the Person Module, access to it also needs to be enabled.
This could be accomplished in many ways, but the most convenient for now is to map the Auditor role to the forum function categories in the Portal Types of both
Person and Person
to make it easier to export these settings later.
Go to Portal Types >> Persons (if you can't find it, put Person on the ID field) and go to Action tab and select "Add Role Information". After that:
● Title: Forum User
Description: Forum users can see information on Persons.
Do not forget to do the same with Person Module.
The security of the discussion threads will be handled by the workflow we defined before. For that we need to enhance it with security configuration. This is done by selecting which permissions to control with the workflow, and then, for each workflow state, how those permissions are mapped to the portal roles.
Go to /portal_workflow/manage_main, navigate to Contents tab >> discussion_thread_workflow >> Permissions tab, and make sure the following permissions
are listed and add them if they are not:
● Access contents information → Regulates who can access properties of an object.
Add portal content → Regulates who can create new objects within another object. In this
case, new Discussion Posts inside a Discussion Thread.
Delete objects → Regulates who can delete objects from inside another object
Modify portal content → Regulates who can modify an object
View → Regulates who is allowed to visit an object directly with the browser
The mapping of the permissions on the previous slide to roles can now be configured in each workflow state. In the States tab, select the draft state and adjust the permissions as in the first illustration above. They establish that only a manager and an owner can look at a thread and make changes to it.
Make sure to always uncheck the left column "Acquire permission settings".
At this point it is important to remember that the Owner role is automatically granted to the user who created the thread.
Then go back to the States tab, select the public state and adjust the permission mappings according to the second illustration above.
In this state, Authors can "Add portal content" meaning they can add Discussion Post objects to a Discussion Thread object.
Adjust the permission mappings for the sticky state in the same way you did for the public state.
Since the Discussion Thread Module Portal Type has a role mapping giving Author role to the forum/user function category, this means that forum users can post replies to public threads.
Notice that Auditors, which are mapped to forum/visitors don't have that permission, and so they can't post replies in this configuration.
Accordingly, adjust the permissions for states closed and hidden according to the respective illustrations.
You will notice that in the closed state, neither Author nor Owner can Add portal content any longer, whereas in the private state, the Auditor role loses his View and Access contents
information privileges, while the Author role loses View, Access contents information and Add portal content rights.
Of course, it's not much use configuring the permissions in the workflow if any user can publish a thread and then enable the other users to post to it.
So navigate back to the discussion_thread_workflow, click on the Transitions tab and select the close transition. In the Properties form there is a Guard area with fields for criteria for protecting a transition. If none of these criteria are defined, anyone can execute this transition. If more than one of criteria is defined, all defined criteria must be met for the transition to be allowed.
Due to the security modelling described earlier, the easiest way to protect the close transition is by restricting it to the Owner role, so that only the original authors put this value in the Role field. The same should be done for the close_action field.
An forum user will want to create a new thread from draft state, so publish transition must allow users to do this action.
As for the other transitions, only the forum administrator should perform them. Since we defined that forum administrators get the Assignor role inside the Discussion Threads. So now place the Assignor value this time in the Role field of all the other transitions.
We have already set Owner to the publish action, so that a user who want to create a new thread will be able to publish it.
However, a hidden thread must not be published by a user. So you can add a new transition named "unhide" to let the Assignor publish the hidden one. Remember the properties to set when you create the unhide and unhide_action transitions, as shown in the slide.
After setting Role in all transitions, you should have a Transitions list as shown in the slide.
To make sure all existing thread objects acquire the permissions you have defined, navigate back to the discussion_thread_workflow and click the Update security settings button.
The workflow configuration dealt with the Discussion Thread objects, but we need to adjust the permissions of the Discussion Thread Module itself, so go into the Zope Management Interface and navigate to the discussion_thread_module object, then click on the Security tab.
There are many permissions on this screen, but only View and Add portal content permissions are important for the Forum configuration. Make sure they are configured as the illustration.
Specifically, Authors need to be able to Add portal content, which in this case are the Discussion Threads.
Now log in to the site with each of the Persons you created previously and try to exercise their permissions.
In ERP5, if a Person has no valid assignments, she can't log in. Check in the Assignments tab of the buggy Person for these two criteria that deactivate assignments:
● Symptom: Assignment is not started. (state is “draft”). Fix: Edit the assignment; action >> start assignment
● Symptom: Assignment has expired (Stop Date < today ) Fix: Edit the assignment; change the Stop Date.