Odoo includes built-in access control mechanisms. A user will only be able to use the features he was granted access to. This means that the library features we created are not accessible by regular users, even the admin user.
Note
Changes in Odoo 12
The admin user is now subject to access control like all other users. In previous Odoo versions, the admin
user was special, and bypassed security rules. This is no longer true, and we need to grant access privileges to be able to access Model data.
The central pieces for access security are the security groups, where the access rules are defined. Access for each user will depend on the groups he belongs to. For our project, we will create a to-do user group, to be assigned to the users we want to have access to this feature.
We give a group read or write access to particular Models
using ACL. For our project, we need to add read and write access to the newly created to-do item model.
Furthermore, we can also set access rules for the record ranges users can access in a particular Model. For our project, we want the T
o-do Items
to be private for each user, so to-do users should only be able to access the records created by themselves. This is done using the security record rules.
Access control is based on groups. A security group is given access to Models
, and this will determine the menu items available to the users belonging to that group. For more fine-grained control, we can also give access to specific menu Items, views, fields, and even data records (with Record Rules
).
The security groups are also organized around apps, and typically each app provides at least two groups: Users
, capable of performing the daily tasks, and Manager
, able to perform all configurations for that app.
Let's create a new security group. In the Settings
top menu, navigate to Users & Companies
| Groups
. Create a new record using the following values:
Application
: Leave emptyName
:To-do User
Inherited
tab: Add theUser types / Internal User
item
This is how it should look like:
The to-do app is not available yet in the Application
selection list, so we added it directly from the Group
form.
We also made it inherit the Internal User
group. This means that members of this group will also be made members of the Inherited
groups (recursively), effectively having the permissions granted to all of them. Internal User
is the basic access group, and app security groups usually inherit it.
Now, we can grant access to specific Models
to the Group /
To-do User
. We can use the Access Rights
tab of the Groups
form for this. Add an item there, using these values:
Name
:To-do Item User Access
Object
: SelectTo-do Item
from the listRead Access
,Write Access
,Create Access
, andD
elete Access
: Checked
Model access can also be managed from the Technical
| Security
| Access Rights
menu item.
We don't need to add access to the Partner
Model because the Group
is inheriting the Internal Users
group, which already has access to it.
We can now try these new security settings, by adding our admin
user to this new Group
:
- Select the
Users & Companies
|Users
menu item, select theMitchell Admin
user from the list, andEdit
the form:
- In the
Access Rights
tab, in theOther
section, we can see aTo-do User
checkbox to enable the security group for this user. Select it, andSave
the form.
If everything was done correctly, you should be able to see the to-do top menu; use it to add to-do items. We should see only our own items and won't be able to access other users'.
When given access to a Model, by default users will be able to access all its records. But in some cases, we need to restrict the particular records each user should be able to access. This is possible using record rules, which define domain filters to automatically be enforced when performing read or write operations.
For example, in our to-do app, the To-do Items
are expected to be private, so we want users to only be able to see their own items. We need a record rule to filter only the records created by the current user:
- The
create_uid
field is automatically added by the framework, and stores the user that created the record, and we can use it to see who owns each record - The current user is available in the
user
variable, auser
variable browse object available in the context where thedomain
filter is evaluated
We can use this in a domain
expression to achieve our goal: [('create_uid', '=', user.id)]
.
Record rules are available in the Settings | Technical | Security | Record Rules
menu. Navigate there and create a new Record Rules
, with the following values:
Name
: A descriptive title, such asTo-do Own Items
Object
: Select the Model from the list,To-do Item
in our caseAccess Rights
: The actions where the rule will be applied; leave all checkedRule Definition
: TheDomain Filter
,[('create_uid', '=', user.id)]
Groups
: The security groups it applies to; select and add theTo-do User
group
This is how the Record Rules
definition will look like:
And we're done. You can now try this new rule by creating a couple of to-do items with both the Admin
and Demo
users. Each should be able to see only their own items. The Record Rules
can be switched off through the box button in the upper-right corner of the form. If you try that and check the to-do item list, you should see all the items from all users.
In previous Odoo versions, the admin
user was special and bypassed access security. In version 12 this has changed, and the admin
account belongs to all app security groups, but is a regular user. We still have a superuser that bypasses access security, but it doesn't have a login.
We can still work as a superuser. When logged in as a user with the Admin \ Setting
group, the Become Superuser
option is in the developer menu, Or, use the Login as superuser
hidden option in the login screen, visible if the Developer mode is enabled.
When the superuser is enabled, in the upper-right corner the current user is shown as OdooBot, and the colors in the upper-right area change to yellow and black stripes, to make it clear the superuser is enabled.
This should be used only if absolutely necessary. The fact that the superuser bypasses access security can lead to data inconsistencies, for example in a multi-company context, and should be avoided.