Record rules are just data records loaded into the ir.rule core model. While the file adding them can be anywhere in the module, the convention is for it to be in the security subdirectory. It is common to have a single XML file with both security groups and record rules.

Unlike groups, in the standard modules, the record rules are loaded in a data section with the noupdate="1" attribute. With this, those records will not be reloaded on a module upgrade, meaning that manual customizations on them are safe and will survive later upgrades.

To stay consistent with the official modules, we should also have our record rules inside a <data noupdate="1"> section.

Record rules can be seen from the GUI at the Settings | Technical | Security | Record Rules menu option, as shown in the following screenshot:

The following are the most important record rule fields used in the example:

• Name (name) is a descriptive title for the rule.
• Object (model_id) is a reference to the model the rule applies to.
• Groups (groups) are the security groups that the rule applies to. If none, the rule is considered global and is applied in a different way (more details follow later).
• Rule definition (domain) is a domain expression with the record filter to apply.

The first record rule we created was for the Employee security group. It uses the [('create_uid', '=', user.id)] domain expression to select only those books where the creation user is the current user. Thus, they will only be able to see the books created by themselves.

The domain expressions used in the record rules run on the server side using ORM objects. Due to this, dot notation can be used on the fields on the left-hand side (the first tuple element). The right-hand side (third tuple element) is a Python expression, evaluated in a context having available the user record object, for the current user and the time Python library.

For the settings security group, we want it to be able to see all the books, independent of who created them in the database. Since it inherits the Employee group, unless we do something about it, it will also be able to see only the books created by itself.

The several (non-global) record rules are joined together using the OR logical operator; each rule adds access and never removes the access. For the Library Manager to have access to all the books, we can add to it a record rule to add access to books created by other users, like this—[('create_uid', '!=', user.id)].

We chose to do it differently and use the special rule [(1, '=', 1)] to unconditionally give access to all book records. While this may seem redundant, remember that otherwise, the Library user rule can be customized in a way that will keep some books out of reach to the Settings user. It is special because the first element of a domain tuple must be a field name; this exact case is one of two cases where that is not true. The special domain [(1, '=', 0)] is never true, but also not very useful in the case of rules, save for some very complicated permission structures.