From a692dbdc9c86255d87372dc50b482b22ea2b2503 Mon Sep 17 00:00:00 2001 From: "Antoine Vandevenne (anv)" Date: Wed, 15 Dec 2021 11:43:42 +0000 Subject: [PATCH] [IMP] developer/*: replace occurrences of "access rule" by "record rule" Both the functional and technical name of the `ir.rule` model is "Record Rule". This commit makes sure that all occurrences of "Access Rule" are replaced by the correct name "Record Rule" as it was easily confused with "Access Rights". Original PR: https://github.com/odoo/documentation/pull/1118 closes odoo/documentation#1422 X-original-commit: 46cb0b8e9bae80e77b2b0d3f6a670b6544a76206 Signed-off-by: Victor Feyens (vfe) Signed-off-by: Antoine Vandevenne (anv) --- .../howtos/rdtraining/B_acl_irrules.rst | 18 +++++++++--------- content/developer/misc/other/guidelines.rst | 9 +++++---- content/developer/reference/backend/data.rst | 2 +- .../developer/reference/backend/security.rst | 4 ++-- 4 files changed, 17 insertions(+), 16 deletions(-) diff --git a/content/developer/howtos/rdtraining/B_acl_irrules.rst b/content/developer/howtos/rdtraining/B_acl_irrules.rst index cc9e6dd7d..bb0720f59 100644 --- a/content/developer/howtos/rdtraining/B_acl_irrules.rst +++ b/content/developer/howtos/rdtraining/B_acl_irrules.rst @@ -199,7 +199,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 @@ -215,7 +215,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 @@ -296,9 +296,9 @@ 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 recordset in "sudo mode", this ignores - all access rules and access rights (although hard-coded group and user checks + 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:: @@ -323,12 +323,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: @@ -373,8 +373,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:: @@ -423,7 +423,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 d7d70e188..62f26f69e 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/backend/data.rst b/content/developer/reference/backend/data.rst index 948e9600b..ae7629089 100644 --- a/content/developer/reference/backend/data.rst +++ b/content/developer/reference/backend/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/backend/security.rst b/content/developer/reference/backend/security.rst index 419d07fdc..38d634bce 100644 --- a/content/developer/reference/backend/security.rst +++ b/content/developer/reference/backend/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