Adding access control security
To get a picture of what information is needed to add access rules to a model, use the web client and go to Settings | Technical | Security | Access Controls List:
This information has to be provided by the module using a data file to load the lines into the ir.model.access model. We will add full access to the employee group on the model. Employee is the basic access group nearly everyone belongs to. The exceptions are external users, such as customers or website visitors.
This is done using a CSV file named security/ir.model.access.csv. Let's add it with the following content:
id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink access_todo_task_group_user,todo.task.user,model_todo_task,base.group_user,1,1,1,1
The filename corresponds to the model to load the data into, and the first line of the file has the column names. These are the columns provided in our CSV file:
- id is the record external identifier (also known as XML ID). It should be unique in our module.
- name is a description title. It is only informative and it's best if it's kept unique. Official modules usually use a dot-separated string with the model name and the group. Following this convention, we used todo.task.user.
- model_id is the external identifier for the model we are giving access to. Models have XML IDs automatically generated by the ORM; for todo.task, the identifier is model_todo_task.
- group_id identifies the security group to give permissions to. The most important ones are provided by the base module. The Employee group is such a case and has the base.group_user identifier.
- perm fields flag the access to grant read, write, create, or unlink (delete) access.
We must not forget to add the reference to this new file in the __manifest__.py descriptor's data attribute. It should look like this:
'data': [ 'security/ir.model.access.csv', 'views/todo_menu.xml', 'views/todo_view.xml', 'views/res_partner_view.xml',
],
As before, upgrade the module for these additions to take effect. The warning message should be gone, and we can confirm that the permissions are OK by logging in with the user demo (password is also demo). If we run our tests now, they should only fail the test_record_rule test case.