diff --git a/content/developer/howtos/rdtraining/B_acl_irrules.rst b/content/developer/howtos/rdtraining/B_acl_irrules.rst index a01a8a3c2..59d37aafd 100644 --- a/content/developer/howtos/rdtraining/B_acl_irrules.rst +++ b/content/developer/howtos/rdtraining/B_acl_irrules.rst @@ -198,7 +198,7 @@ Since the "demo" user was not made a real-estate agent or manager, they should not even be able to see the real-estate application. Use a private tab or window to check for this (the "demo" user has the password "demo"). -Access Rules +Record Rules ============ .. seealso:: The documentation related to this topic can be found at @@ -214,7 +214,7 @@ Access rights can grant access to an entire model but often we need to be more specific: while an agent can interact with properties in general we may not want them to update or even see properties managed by one of their colleagues. -Access *rules* provide that precision: they can grant or reject access to +Record *rules* provide that precision: they can grant or reject access to individual records: .. code-block:: xml @@ -294,10 +294,10 @@ do so. There are two main ways to bypass existing security checks in Odoo, either wilfully or as a side-effect: -* The ``sudo()`` method will create a new recorset in "sudo mode", this ignores - all access rules and access rights (although hard-coded group and user checks +* The ``sudo()`` method will create a new recordset in "sudo mode", this ignores + all access rights and record rules (although hard-coded group and user checks may still apply). -* Performing raw SQL queries will bypass access rules and access rights as a +* Performing raw SQL queries will bypass access rights and record rules as a side-effect of bypassing the ORM itself. .. exercise:: @@ -322,12 +322,12 @@ Programmatically checking security At the end of this section, the creation of the invoice should be resilient to security issues regardless to changes to ``estate``. -In Odoo, access rights and access rules are only checked *when performing data +In Odoo, access rights and record rules are only checked *when performing data access via the ORM* e.g. creating, reading, searching, writing, or unlinking a record via ORM methods. Other methods do *not* necessarily check against any sort of access rights. -In the previous section, we bypassed the access rules when creating the invoice +In the previous section, we bypassed the record rules when creating the invoice in ``action_sold``. This bypass can be reached by any user without any access right being checked: @@ -372,8 +372,8 @@ Explicit security checks can be performed by: verifies that the current user is allowed to perform the operation on *every* record of the set. -.. warning:: Checking access rights and checking access rules are separate - operations, if you're checking access rules you usually want to +.. warning:: Checking access rights and checking record rules are separate + operations, if you're checking record rules you usually want to also check access rights beforehand. .. exercise:: @@ -422,7 +422,7 @@ As before, because this is based on non-trivial records it's easier for a user to relax rules than to tighten them so it makes sense to default to a relatively stronger security model. -Multi-company rules are simply access rules based on the ``company_ids`` or +Multi-company rules are simply record rules based on the ``company_ids`` or ``company_id`` fields: * ``company_ids`` is all the companies to which the current user has access diff --git a/content/developer/misc/other/guidelines.rst b/content/developer/misc/other/guidelines.rst index fe20be43d..bbdafd243 100644 --- a/content/developer/misc/other/guidelines.rst +++ b/content/developer/misc/other/guidelines.rst @@ -71,10 +71,11 @@ models. | |-- plant_order.py (another main model) | |-- res_partner.py (inherited Odoo model) -Concerning *security* and access rights and rules two main files should be used. -First one is the definition of access rights done in a ``ir.model.access.csv`` -file. User groups are defined in ``_groups.xml``. Access rules are -defined in ``_security.xml``. +Concerning *security*, three main files should be used: + +- First one is the definition of access rights done in a :file:`ir.model.access.csv` file. +- User groups are defined in :file:`_groups.xml`. +- Record rules are defined in :file:`_security.xml`. .. code-block:: text diff --git a/content/developer/reference/addons/data.rst b/content/developer/reference/addons/data.rst index 948e9600b..ae7629089 100644 --- a/content/developer/reference/addons/data.rst +++ b/content/developer/reference/addons/data.rst @@ -7,7 +7,7 @@ Data Files Odoo is greatly data-driven, and a big part of modules definition is thus the definition of the various records it manages: UI (menus and views), -security (access rights and access rules), reports and plain data are all +security (access rights and record rules), reports and plain data are all defined via records. Structure diff --git a/content/developer/reference/addons/security.rst b/content/developer/reference/addons/security.rst index 419d07fdc..38d634bce 100644 --- a/content/developer/reference/addons/security.rst +++ b/content/developer/reference/addons/security.rst @@ -79,14 +79,14 @@ will have all three of create, read, and update. .. _reference/security/rules: -Access Rules +Record Rules ============ Record rules are *conditions* which must be satisfied in order for an operation to be allowed. Record rules are evaluated record-by-record, following access rights. -Access rules are default-allow: if access rights grant access and no rule +Record rules are default-allow: if access rights grant access and no rule applies to the operation and model for the user, the access is granted. .. class:: ir.rule