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:

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:

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:

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:

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:

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.