[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#1421

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

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

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 ``<module>_groups.xml``. Access rules are
-defined in ``<model>_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:`<module>_groups.xml`.
+- Record rules are defined in :file:`<model>_security.xml`.
 
 .. code-block:: text
 

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

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