In this chapter, we will see how to:
- Create security groups and assign them to users
- Add security access to models
- Limit access to fields in models
- Limit record access using record rules
- Use security group to activate features
In order to concisely get the point across, the recipes in this chapter make small additions to an existing module. We chose to use the module created by the recipes in Chapter 3, Creating Odoo Modules. To better follow the examples here, you should have that module created and ready to use.
Security access in Odoo is configured through security groups: permissions are given to groups and then groups are assigned to users. Each functional area has base security groups provided by a central application.
When the addon modules extend an existing application, they should add permissions to the corresponding groups, as shown in the Add security access to models recipe later.
When the addon modules add a new functional area, not yet covered by an existing central application, they should add the corresponding security groups. Usually, we should have at least the user and manager roles.
Taking the Library example we introduced in Chapter 3, Creating Odoo Modules, it doesn't fit neatly in any of the Odoo core apps, so we add the security groups for it.
This recipe assumes you have an instance ready, with the my_module available, as described in Chapter 3, Creating Odoo Modules
.
To add new access security groups to a module, perform the following steps:
- Make sure that the addon module manifest
__openerp__.pyhas thecategorykey defined:'category': 'Library',
- Add the new
security/library_security.xmlfile to the manifestdatakey:'data': [ 'security/library_security.xml', 'views/library_book.xml', ], - Add the new XML file for the data records at
security/library_security.xml, starting with an empty structure:<?xml version="1.0" encoding="utf-8"?> <odoo> <data noupdate="0"> <!-- Data records go here --> </data> </odoo> - Add inside the data XML element the
recordtags for the two new groups:<record id="group_library_user" model="res.groups"> <field name="name">User</field> <field name="category_id" ref="base.module_category_library"/> <field name="implied_ids" eval="[(4, ref('base.group_user'))]"/> </record> <record id="group_library_manager" model="res.groups"> <field name="name">Manager</field> <field name="category_id" ref="base.module_category_library"/> <field name="implied_ids" eval="[(4, ref('group_library_user'))]"/> <field name="users" eval="[(4, ref('base.user_root'))]"/> </record>
If we upgrade the addon module, these two records will be loaded and we will be able to see them at the menu option Settings | Users | Groups:
Addon modules are organized in functional areas, or major applications, such as Accounting & Finance, Sales, or Human Resources. These are defined by the category key in the manifest file.
If a category name does not exist yet, it will be automatically created. For convenience, a base.module_category_<category> XML ID will also be generated for the new category name in lowercase letters, replacing spaces with underscores. This is useful to relate security groups with application categories.
In our example, we used the Library category name, and it generated a base.module_category_library XML identifier.
By convention, the data files adding security related elements should be placed inside a security subdirectory.
The order in which the files are declared in the data attribute is important, since you can't use an identifier before it has been defined. We may want to use references in views for the security groups we had defined, so it's best to place the security data file at the top of the list before the ACL definition files and the other user interface data files.
Security groups should be added using an XML file. It can add records that we want to be customizable by the end users. To prevent those possible changes being lost on a module upgrade, we should add those records inside a <data noupdate="1"> element. This is usually the case for security record rules, discussed in the Limit record access using record rules recipe later.
But for security groups, the practice used in Odoo core addon modules is to have them defined inside a <data noupdate="0"> element. This means that they will be rewritten on a module upgrade, and so should not be directly customized. Customization should instead be done by creating new groups that inherit from the default ones.
Groups are stored in the res.groups model, and its most important columns are as follows:
name: This is the group's display name.category_id: This is a reference to the application category, and is used to organize the groups in the users form.implied_ids: These are the other groups to inherit permissions from.users: This is the list of users belonging to this group. In the new addon modules, usually we want the admin user to conveniently belong to the application's manager group.
The first security group uses as implied_ids the base.group_user. This is the employee user, and is the basic security group all the backend users are expected to share.
The second security group sets a value on the users field to assign it to the administrator user, that has the base.user_root XML ID.
Users belonging to a security group will automatically belong to its implied groups. If Library Manager has implied the Library User group, assigning it to a user will also include him in the Library User group.
Also, the access permissions granted by security groups are cumulative. A user has some permission in any of the groups he belongs to (directly or implied) grants that permission.
Some security groups are shown in the user form as a selection box instead of individual checkboxes. This happens when the involved groups are in the same application category and are linearly interrelated through implied_ids. For example, Group A has implied Group B, and Group B has implied Group C.
Note that the relations defined in the preceding fields also have reverse relations that can be edited in the related models, such as security groups and users.
Setting values on reference fields, such as category_id and implied_ids, is done using the related records XML IDs and some special syntax.
For Many2one relations, the ref attribute is used to link with the record with the corresponding XML ID. For One2many fields, such as implied_ids, the eval attribute is used with a list of tuple commands. For example, the tuple 4 as the first element adds the references in the next element or elements. This syntax is explained in detail in Chapter 9, Module Data.
Also noteworthy is the special base.group_no_one security group. In the previous Odoo versions, it was used for advanced features hidden by default, and only made visible when the Technical Features flag was activated. Since version 9.0 this has changed, and those features are made visible as long as the Developer Mode is activated.
The access permissions granted by security groups are cumulative only. There is no way to deny an access given by some group. This means a manually created group to customize permissions should inherit from the closest group with fewer permissions than those intended (if any), and then add all the remaining permissions needed.
Groups also have available these additional fields:
- Menus (the
menu_accessfield): These are the menu items the group has access to - Views (the
view_accessfield): These are the UI views the group has access to - Access rights (the
model_accessfield): These are the access it has on models, detailed in the Add security access to models recipe - Rules (the
rule_groupsfield): These are the record level access rules that apply to the group, detailed in the Limit record access using record rules recipe - Notes (the
commentfield): This is a description or comment text for the group