Access rights and scopes

Creating a user is described in chapter 5. This chapter covers what comes next: setting precisely who reaches what, and knowing how to diagnose an unexpected situation.

The principle

Understanding how Odoo decides whether a user sees a document avoids proceeding by trial and error. Everything rests on a single object, the access right, and on the way those rights combine.

What an access right carries

An access right names a type of document and states three things.

What it carries	What that governs
The operations	Read, create, write, delete: those the right allows, taken separately.
A group, or none	Who is concerned. That point changes the effect of the right entirely.
A condition	Called a domain, it bounds the right to part of the documents: those where the user is the salesperson, those of their company, those of their team. Left empty, it holds for all of them.

A single type of document therefore carries several access rights, and it is their combination that settles what each person sees.

Groups

A group is a named set of rights. The user does not receive those rights one by one: they receive groups, and the rights follow.

A group may imply another one: its members then automatically belong to the implied group, and accumulate the rights of both. That is what builds the levels of a single domain, the higher level implying the lower one and adding its own rights to it.

With a group, the right grants

A right attached to a group grants the operations it lists, on the documents its condition retains, to the members of that group.

Rights of that kind concerning the same user combine with or: it is enough for one of them to accept the document for the user to see it. Adding one therefore widens the scope.

Without a group, the right restricts

A right with no group applies to everyone, with no exception, the administrator included. It grants nothing: it takes away everything its condition does not retain. Rights of that kind combine with and with everything else. It is the only mechanism that really restricts.

Partitioning between companies is the most common example. On sales orders, a right with no group carries the condition "the company of the document is among the active companies": on its own, it makes the multi-company setup watertight.

A user's final scope is therefore: every right with no group, and at least one of the group rights that concern them.

Two symptoms, two causes

If no group right grants the operation requested, the user receives an explicit refusal, which names the groups liable to allow it. If a right grants it but the conditions exclude every document, they see an empty screen, with no error message. That difference in symptom already points to where to look.

A complete example

The sales levels illustrate the whole model. On sales orders, Odoo ships the following rights.

Right shipped	What it does
Attached to the group User: Own Documents Only	Grants reading, creation and writing, on the condition that "the salesperson is me, or the salesperson is not set".
Attached to the group User: All Documents	Grants the same operations, with no condition.
Attached to the group Administrator	Grants deletion as well, with no condition.
With no group	Takes away from everyone the documents whose company is not among the active companies.

The User: All Documents level implies the previous one: the user is therefore in both groups and falls under the first two rights. They combine with or: "my documents" or "everything". The second wins, and the user sees the whole set. The right with no group applies whatever their level.

Working without breaking anything

These mechanisms call for a few rules of conduct.

1. Do not modify a right shipped by Odoo. It applies to every member of its group, including uses you do not know about, and your modification is visible nowhere to whoever diagnoses the situation later. Create an additional right instead, targeting a dedicated group.
2. To widen, add a group right, rather than extending the condition of an existing right. The effect is the same for the people targeted, with no consequence for the others.
3. To restrict, only a right with no group gets there: and it imposes itself on everyone, the administrator included. Check it on a real case before leaving it in place.
4. To withdraw an access, remove the group that grants it. Looking for something that might forbid it is a dead end: that mechanism does not exist.
5. Create a dedicated group rather than adapting a standard one: and really create it, do not duplicate it (see section 6.1.8). A group belonging to no module is an addition; a modified standard group is a debt.
6. Have lasting additions carried by a module. A right typed straight into the database exists on that database only: it is found neither on the test environment, nor after a restore, nor on a database created later.

What duplicating a group does (and does not) copy

Duplicating a group to make a variant of it looks economical. The result is not the expected one: depending on the item, the copy receives independent instances or mere links to the originals.

Item of the group	What the copy gets
Access rights, conditions included	Duplicated. The copy owns its own rights, editable with no effect on the original group.
Menus and views reachable	Shared. Nothing is recreated: the same menus and the same views are now attached to both groups.
Implied groups	Shared. The copy pulls in the same groups as the original.
Members	Carried over. The users of the original group end up in the copy.

Assigning the access levels

The domains and their levels

The Access Rights tab of the user record presents the functional domains grouped by category. Each domain is set from a dropdown list offering its levels, from the most restricted to the widest. A domain left at No (or at the label standing for it) means the user has no access at all to that scope.

Above those domains, the Roles group carries the user's general role and, in a multi-company setup, the companies they reach.

For sales, for example:

Level	Scope granted
No	No access to sales documents. That is the default value of any domain not assigned.
User: Own Documents Only	Sees only the quotations and orders where they are the salesperson.
User: All Documents	Sees every sales document, whoever the salesperson is, and can edit them. They cannot delete them.
Administrator	Full access, deletion and configuration of the application included.

1. Open Settings › Users & Companies › Users and select the user.
2. Open the Access Rights tab.
3. For each domain that matters, choose the level from its dropdown list; leave the others at No.
4. Save.

What "own documents only" really restricts

That level is the one that surprises most. It does not hide an application: it restricts the records visible to those the user is responsible for.

The field that determines "their" documents varies with the application: the salesperson on an order, the assignee on a task, the employee on an expense. In case of doubt, the check is made on a real case rather than by deduction (see section 6.6).

Going beyond the standard levels

Some groups belong to no domain: they therefore appear in no dropdown list. They are the ones that open the cross-cutting or secondary capabilities: handling several units of measure, reaching the pricelists, working in several currencies.

To grant or withdraw a right outside any domain:

1. Enable developer mode (see chapter 3).
2. Open the user's record, Access Rights tab.
3. Scroll down to the Extra Rights section, which only appears in developer mode: each right outside any domain is a checkbox there.
4. Tick or untick, then save and check the result obtained (see section 6.6).

The operation can also be carried out from the group, which suits handling several people at once better: open Settings › Users & Companies › Groups, then the Users tab of the group wanted.

To withdraw a right outside any domain, the simplest is to start from the person rather than look for the group:

1. Open Settings › Users & Companies › Users and select the user.
2. Click the Groups smart button: the list of their groups appears, with the Scope each one falls under.
3. Open the group to withdraw.
4. In the Users tab, remove the person.
5. Save.

Reusing an existing profile

Rebuilding a user's rights by hand for a colleague in the same position is long and unreliable. Duplication reproduces the profile identically.

1. Open Settings › Users & Companies › Users.
2. Select the user serving as the reference.
3. Click Actions then Duplicate.
4. Odoo creates a copy carrying the mention (copy) in the name and in the login, with the same groups and the same access levels.
5. Replace the name and the email address with those of the newcomer.
6. Check the companies reachable and the default company.
7. Save, then send the invitation.

Internal, portal and public users

Three kinds of user coexist, and the distinction has direct consequences.

Kind	Access and use
Internal	Employee of the company. Reaches the management interface according to their rights.
Portal	External third party: customer, vendor, subcontractor. Reaches only their own documents, in a simplified interface, without ever entering the management interface.
Public	Unidentified visitor of the website. Reaches published content only.

An external user carries an explicit banner at the top of their record, which avoids confusing them with a colleague.

The procedure for opening a portal access is described in chapter 5.

Partitioning several companies

When the database holds several entities, each user has a list of companies reachable and a default company.

1. Open the user's record, Access Rights tab.
2. Fill in the Companies they have access to.
3. Fill in the Default Company, active when the session opens.

Inspecting the rights applied

Rather than reconstructing the effect of the groups in your head, Odoo displays the result.

1. Enable developer mode (see chapter 3).
2. Open the record of the user concerned.
3. Two smart buttons appear at the top of the form, each carrying its count: - Groups: the complete list of the groups applied, implications included. It has two columns: Scope, which states the domain the group falls under, and Name. An empty Scope column flags a group outside any domain, one of those the dropdown lists do not offer; - Access Rights: the rights attached to those groups, one per row, with the type of document, the operations allowed and the scope condition. The count commonly runs into the hundreds: that is normal, every application brings its own.

Those two screens are inventories: they render the state obtained. They allow neither creation nor deletion, but the values displayed stay editable there. Treat them as consultation screens: a change made here bears on the general configuration, not on the single user being inspected.

Going further

For a need the standard levels do not cover, the technical screens give access to the objects themselves. They assume developer mode is active.

Screen	Contents
Settings › Users & Companies › Groups	The existing groups, their members, the groups they imply and the rights they carry.
Settings › Technical › Security › Scopes	The functional domains and the order of their levels.
Settings › Technical › Security › Access Rights	Every access right of the database, with or without a group.

An access right reads in four points: the type of document concerned, the group it applies to (a right with no group imposes itself on everyone), the operations it carries and the condition that bounds its scope. The list tells the two kinds apart by a coloured tag, and groups by group, by type of document or by kind.

Tracing the changes

On sensitive documents, Odoo records in the chatter (the exchange and history area present at the bottom of every document, described in section 4.1) who changed what, when, and what the previous value was. The tracking bears on the fields declared as tracked, and that scope varies from one application to another (see section 4.1).

For accounting operations, locking the periods completes that tracking by preventing any change before a given date (see chapter 14).

Good practice

Embodying a typical position

Odoo has no "profile" object: nothing lets you declare a position and assign it in one gesture. Two techniques nevertheless produce that effect, with different properties.

Technique	Properties
Reference user, duplicated at every arrival	No technical notion to create, no developer mode. On the other hand the template is only one record among others: nothing marks it as a reference, and a change to the template does not carry over to the people already created.
Position group, implying others	A named object, assigned in one go, and editable for everyone at once: adding a right to the group grants it to all its members. Requires developer mode, and is better carried by a module.

For the first, the procedure is the one in section 6.3.

For the second:

1. Enable developer mode (see chapter 3).
2. Open Settings › Users & Companies › Groups and create a group carrying the name of the position.
3. In the Dependencies tab, fill in the Implied Groups: the levels and the rights the position must grant.
4. Assign that single group to the people concerned, from its Users tab.