It's common for the addon modules to add new models. For example, in the previous chapter we had examples adding a new Library Books model.
It is easy to miss the creation of security access for the new models defined in an addon module if you test it using the convenient admin user, because admin bypasses all the security checks.
However, models with no ACLs will trigger a warning log message on loading, informing about the missing ACL definitions: The model library.book has no access rules, consider adding one. To avoid that, you should watch for such messages during tests, and before publishing your code make sure you run the tests with the demo user rather than admin.
So, for new models to be usable by non-admin users, we need to define their security access control lists, so that Odoo knows how it should access them and what operations each user group should be allowed.
We will take the module created in Chapter 3, Creating Odoo Modules and add to it the missing ACLs.
my_module should already contain the models/library_book.py Python file creating the library.book model. We will now add a data file describing this model's security access control by performing the following steps:
- Edit the
__openerp__.pymanifest file to declare a new data file:data: [ # …Security Groups 'security/ir.model.access.csv', # …Other data files ] - Add to the module a new file
security/ir.model.access.csv, with the following lines:id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink access_library_book_user,library.book.user,model_library_book,base.group_user,1,0,0,0 access_library_book_admin,library.book.admin,model_library_book,base.group_system,1,1,1,1
We should then upgrade the module to have these ACL records added to our Odoo database. More importantly, if we sign in to a demonstration database using the demo user, we should be able to access the Library menu option without any security errors.
The security access control lists are stored in the core ir.model.access model. We just need to add to it the records describing the intended access rights for each user group.
Any type of data file would do, but the common practice is to use a CSV file. The file can be placed anywhere inside the addon module directory, but the convention is to have all the security related files inside a security subdirectory.
The first step in our recipe declares this new data file to the manifest and the second adds the file describing the security access control rules. The CSV file must be named after the model where the records will be loaded, so the name used is not just a convention and is mandatory.
If the module also creates new security groups, its data file should be declared before the ACLs' data file, since you may want to use them for the ACLs and so they must already be created when the ACL file is processed.
The columns in the CSV file are as follows:
id: This is the XML ID internal identifier for this rule. Any unique name inside the module would do, but the convention is to useaccess_<model>_<group>.name: This is a title for the access rule and, by convention, the common practice is to use aaccess.<model>.<group>name.model_id:id: This is the XML ID for the model. Odoo automatically assigns such an ID to models with a formatmodel_<name>, using the model's_namewith underscores instead of dots. If the model was created in a different addon module, a fully qualified XML ID is needed, including the module name.group_id:id: This is the XML ID for the user group. If left empty, it applies to all the users. The base module provides some basic groups, such asbase.group_user, for all the employees andbase.group_systemfor the administration user. Other apps can add their own user groups.perm_read: This can read the model records (0 or 1).perm_write: This can update the model records (0 or 1).perm_create: This can add new model records (0 or 1).perm_unlink: This can delete model records (0 or 1).
The CSV file we used adds read only access to the Human Resources | Employee standard security group, and full write access to the Administration | Settings group.
The Employee user group, base.group_user, is particularly important because the user groups added by the Odoo standard apps inherit from it. This means that if we need a new model to be accessible by all the backend users, regardless of the specific apps they work with, we should add that permission to the Employee group.
The resulting ACLs can be viewed from the GUI in Settings | Technical | Security | Access Controls List, as shown in the following screenshot:
Some people find it easier to use this user interface to define ACLs and then use the export feature to produce a CSV file.
It would make sense for us to give this permission to the Library user and Library manager groups defined in the Create security Groups and assign them to Users recipe. If you followed that recipe, it's a good exercise to then follow this one, adapting the group identifiers to the Library ones.
It's important to note that the access lists provided by the addon modules should not be directly customized, since they will be reloaded at the next module upgrade, destroying any customization that could have been done from the GUI.
To customize ACLs, two approaches can be used. One is to create new security groups that inherit from the one provided by the module and add additional permissions on it, but this allows only to add, not to remove. A more flexible approach can be to uncheck the Active flag to false on the particular ACL lines, to disable them. It is not visible by default, so we need to edit the tree view to add the <field name="active" /> column. We can also add new ACL lines for additional or replacement permissions. On a module upgrade, the deactivated ACLs won't be reactivated and the added ACL lines won't be affected.
It's also worth noting that ACLs only apply to regular models and don't need to be defined for Abstract or Transient models. If defined, these will be disregarded and a warning message will be triggered into the server log.