============= Access rights ============= *Access rights* are permissions that determine the content and applications users can access and edit. In Odoo, these permissions can be set for individual users or for groups of users. Limiting permissions to only those who need them ensures that users do not modify or delete anything they should not have access to. **Only** an *administrator* can change access rights. .. danger:: Making changes to access rights can have a detrimental impact on the database. This includes *impotent admin*, which means that no user in the database can make changes to the access rights. For this reason, Odoo recommends contacting an Odoo Business Analyst, or our Support Team, before making changes. .. tip:: A user **must** have the specific *Administration* access rights set on their user profile, in order to make changes on another user's settings for access rights. To access this setting, navigate to :menuselection:`Settings app --> Manage users --> select a user --> Access Rights tab --> Administration section --> Administration field`. Once at the setting, an already existing administrator **must** change the setting in the :guilabel:`Administration` field to :guilabel:`Access Rights`. Once complete, click :guilabel:`Save` to save the changes, and implement the user as an administrator. Manage roles ============ :ref:`Individual users ` are assigned a *Role* when they are added to the database. Roles determine the level of access a user has, while the specific access rights associated with each role are defined by :ref:`groups `. The four available roles are: - *Administrator*: An internal user with access to technical features, product creation, export, and other advanced permissions. - *User*: An internal user that typically has access to the back end and can create and edit records but has less overall access than an administrator. - *Portal*: A customer or supplier who accesses their own data through the portal. - *Public*: A website visitor or other external user. They generally have the least access. .. _access-rights/user-permissions: Manage user permissions ======================= The access rights for :ref:`individual users ` are set when the user is added to the database, but they can be adjusted at any point in the user's profile. To make changes to a user's rights, click the desired user to edit their profile. .. image:: access_rights/navigate-to-users-menu.png :alt: Users menu in the Users & Companies section of the Settings app of Odoo. On the user's profile page, in the :guilabel:`Access Rights` tab, scroll down to view the current permissions. The permissions available on the *Access Rights* tab are determined by the groups associated with the user's role. Roles provide a predefined set of permissions, while groups define the specific access rights granted to users. For each app, use the drop-down menu to select what level of permission this user should have. The options vary for each section, yet the most common are: :guilabel:`Blank/None`, :guilabel:`User: Own Documents`, :guilabel:`User: All Documents`, or :guilabel:`Administrator`. The :guilabel:`Administration` field in the :guilabel:`Access Rights` tab has the following options: :guilabel:`Settings` or :guilabel:`Access Rights`. .. image:: access_rights/user-permissions-dropdown-menu.png :alt: The Sales apps drop-down menu to set the user's level of permissions. .. _access-rights/specific-user-permissions: Manage specific permissions --------------------------- While access rights are typically assigned in bundles under specific roles, they can also be set as explicit permissions. .. example:: When a user is assigned the :guilabel:`Administrator` permission for **Timesheets**, it gives them full access to that app. That user, while holding full access, can *still* have their ability to manage *their own* timesheets restricted — such as in the case of a salaried payroll administrator who does not need to track time. To manage specific permissions, :ref:`developer mode ` must be enabled. After that, navigate to the :menuselection:`Settings` app. Then click :guilabel:`Manage Users`, select a user, and go to the :guilabel:`Technical Access Rights` tab. From here, :guilabel:`Groups` can be edited, and specific access rights can be managed across the various sections. If no changes are made to these groups, then their permissions will mirror the selections made in the :guilabel:`Access Rights` tab. - :guilabel:`Selected groups`: a list of detailed access rights, set by choices made in the :guilabel:`Access Rights` tab. - :guilabel:`Groups added automatically`: *implied* permissions that are *inherited* with the explicit permissions already granted to the user. The values here will match the values listed under a given *Group*'s form located under the :menuselection:`Users & Companies --> Groups` menu, in the :guilabel:`Inherited` tab. .. image:: access_rights/tech-access-rights.png :alt: The technical access rights tab opened up for a user profile. .. example:: When the *Sales Administrator* permission set is assigned to a user, the *Canned Responses Administrator* permissions are inherited automatically. These assignments are reflected across the values listed in the :guilabel:`Selected Groups` and :guilabel:`Groups added automatically` tables, respectively. To add a permission to this user profile, click :guilabel:`Add a line` in the :guilabel:`Selected groups` table, and then add permissions to this user profile. To remove a permission, click the :icon:`fa-times` :guilabel:`(cancel)` icon at the end of that permission's row. .. warning:: Removing permissions from the :guilabel:`Selected Groups` list can impact what permissions are listed in the :guilabel:`Groups added automatically` list, since selected permission groups inform what permission groups are added automatically. Clicking on the permission itself will open a group management form. Learn more about :ref:`managing groups `. Any permission in the :guilabel:`Groups added automatically` section is implied or required by the permission shown in the :guilabel:`Selected groups` section. These cannot be removed, but more users can be given these permissions by clicking on the permission itself, and then adding the user to that permission's group. .. note:: - Any permission in green is already provided by another permission (for example, setting the :guilabel:`Website` app's permission to :guilabel:`Editor and Designer` will also give that user the :guilabel:`Restricted Editor` permission). - Any permissions in red are conflicting and cannot be active at the same time. - Any permissions in *italics* are implied by a :guilabel:`Selected group` (these are usually found in the :guilabel:`Groups added automatically`). .. _access-rights/groups: Create and modify groups ======================== *Groups* are app-specific sets of permissions that are used to manage common access rights for a large amount of users. Administrators can modify the existing groups in Odoo, or create new ones to define rules for models within an application. To access groups, first activate Odoo's :ref:`developer mode `, then go to :menuselection:`Settings app --> Users & Companies --> Groups`. .. image:: access_rights/click-users-and-companies.png :alt: Groups menu in the Users & Companies section of the Settings app of Odoo. To create a new group from the :guilabel:`Groups` page, click :guilabel:`Create`. Then, from the blank group form, select an :guilabel:`Application`, and complete the group form (detailed below). To modify an existing group, click an existing group from the list displayed on the :guilabel:`Groups` page, and edit the contents of the form. Enter a :guilabel:`Name` for the group and select the checkbox next to :guilabel:`Share Group`, if this group was created to set access rights for sharing data with some users. .. important:: Always test the settings being changed to ensure they are being applied to the correct users. The group form contains multiple tabs for managing all elements of the group. In each tab, click :guilabel:`Add a line` to add a new row for users or rules, and click the :icon:`fa-times` :guilabel:`(cancel)` icon to remove a row. .. image:: access_rights/groups-form.png :alt: Tabs in the Groups form to modify the settings of the group. - :guilabel:`Users` tab: lists the current users in the group. Users listed in black have administrative rights. Users without administrative access appear in blue. Click :guilabel:`Add a line` to add users to this group. - :guilabel:`Inherited` tab: Inherited means that users added to this group are automatically added to the groups listed on this tab. Click :guilabel:`Add a line` to add inherited groups. .. example:: For example, if the group *Sales/Administrator* lists the group *Website/Restricted Editor* in its :guilabel:`Inherited` tab, then any users added to the *Sales/Administrator* group automatically receive access to the *Website/Restricted Editor* group, as well. - :guilabel:`Menus` tab: defines which models the group can have access to. Click :guilabel:`Add a line` to add a specific menu. - :guilabel:`Views` tab: lists which views in Odoo the group has access to. Click :guilabel:`Add a line` to add a view to the group. - :guilabel:`Access Rights` tab: lists the first level of rights (models) that this group has. The :guilabel:`Name` column represents the name for the current group's access to the model selected in the :guilabel:`Model` column. To link a new access right to a group, click :guilabel:`Add a line`. Select the appropriate model from the :guilabel:`Model` drop-down, then enter a name for the access right in the :guilabel:`Name` column. For each model, enable the following options as appropriate: - :guilabel:`Read`: Users can see the object's existing values. - :guilabel:`Write`: Users can edit the object's existing values. - :guilabel:`Create`: Users can create new values for the object. - :guilabel:`Delete`: Users can delete values for the object. .. tip:: While there are no conventions for naming access rights, it is advisable to choose a name that identifies its purpose. For example, the access that purchase managers have to the :guilabel:`Contact` model could be named `res.partner.purchase.manager`. This consists of the technical name of the model, followed by a name identifying the group of users in question. .. image:: access_rights/name-field.png :alt: Name of access rights to a model. To find the model's technical name from the current view, first enter a placeholder text in the :guilabel:`Name` field, then click the :guilabel:`Model` name, then the :icon:`fa-arrow-right` :guilabel:`(Internal link)` icon. - :guilabel:`Record Rules`: lists the second layer of editing and visibility rights. :guilabel:`Record Rules` overwrite, or refine, the group's access rights. Click :guilabel:`Add a line` to add a record rule to this group. For each rule, choose values for the following options: - :guilabel:`Apply for Read`. - :guilabel:`Apply for Write`. - :guilabel:`Apply for Create`. - :guilabel:`Apply for Delete`. .. important:: Record rules are written using a *domain*, or conditions that filter data. A domain expression is a list of such conditions. For example: `[('mrp_production_ids', 'in', user.partner_id.commercial_partner_id.production_ids.ids)]` This record rule is to enable MRP consumption warnings for subcontractors. Odoo has a library of preconfigured record rules for ease of use. Users without knowledge of domains (and domain expressions) should consult an Odoo Business Analyst, or the Odoo Support Team, before making changes. .. _general/users/access_rights/timeouts: Session and inactivity timeouts ------------------------------- When the `auth_timeout` module is installed, administrators can configure automatic logout rules for users assigned to a specific user group. This module may be installed automatically by certain localizations (for example, the Australian Payroll localization). Once installed, a *Timeouts* tab appears on user group forms. This tab allows administrators to define how long users can remain logged in under different conditions. Two types of timeouts can be configured: Inactivity timeout ~~~~~~~~~~~~~~~~~~ *Inactivity timeout* controls whether users are automatically logged out after a period of inactivity. To enable inactivity timeout, click the *Timeouts* tab and select the :guilabel:`Inactivity` checkbox. Next, choose either :guilabel:`Screen lock` or :guilabel:`Screen lock with two-factor authentication` from the drop-down menu. This determines whether the user must complete 2FA verification when logging back in. Then, enter the desired amount of time before enforcing screen lock, and select a unit of measure from the drop-down menu. Inactivity can be measured in minutes, hours, or days. Session timeout ~~~~~~~~~~~~~~~ *Session timeout* controls whether users are logged out after a fixed session duration, regardless of activity. To enable session timeout, click on the *Timeouts* tab, and select the :guilabel:`Session` checkbox. Next, choose either :guilabel:`Logout` or :guilabel:`Logout with two-factor authentication` from the drop-down menu. This determines whether the user must complete 2FA verification when logging back in. Then, enter the desired amount of time before the user is logged out, and select a unit of measure from the drop-down menu. Session timeouts can be measured in minutes, hours, or days. .. _access-rights/superuser: Superuser mode ============== *Superuser mode* allows the user to bypass record rules and access rights. To activate *Superuser mode*, first, activate :ref:`developer mode `. Then, navigate to the *debug* menu, represented by a :icon:`fa-bug` :guilabel:`(debug)` icon, located in the top banner. Finally, towards the bottom of the menu, click :guilabel:`Become Superuser`. .. important:: Only users with *Settings* access for the *Administration* section of the *Access Rights* (in their user profile) are allowed to log in to *Superuser mode*. .. danger:: *Superuser mode* allows for circumvention of record rules and access rights, and therefore, should be exercised with extreme caution. Upon exiting *Superuser mode*, users may be locked out of the database, due to changes that were made. This can cause *impotent admin*, or an administrator without the ability to change access rights/settings. In this case contact Odoo Support here: `new help ticket `_. The support team is able to restore access using a support login. To leave *Superuser mode*, log out of the account, by navigating to the upper-right corner, and clicking on the :guilabel:`OdooBot` username. Then, select the :guilabel:`Log out` option. .. tip:: An alternative way to activate *Superuser mode* is to log in as a superuser. To do that, navigate to the login screen, and enter the appropriate :guilabel:`Email` and :guilabel:`Password`. Instead of clicking :guilabel:`Login`, click :guilabel:`Log in as superuser`.