In Odoo can be found multiple different methods for filtering and searching records. Each of them is designed with their own uniqueness which makes it more useful in certain cases than others, even though sometimes it may be confusing which one is the right to use. In this post we will go through some of the most used lookup methods and focus on when each of them should be used.

We will cover the following methods:

• ​browse​
• ​search​
• ​filtered​
• ​filtered_domain​

Browse

The method browse​ returns a recordset for the provided IDs​ in the current environment. In case the method is called without any ID​ it will return an empty recordset. This method creates recordset for the IDs without fetching the actual data immediately from the database. It is useful to use when list of IDs need to be converted into recordset.

Search

The search​ method can accept multiple arguments:

• ​domain​: A list of domains to be searched by. An empty list will return all records
• ​offset​: Number of results to ignore. Usually used during page pagination
• ​limit​: Maximum number of results to return
• ​order​: Specified order of records

This method based on the provided arguments creates a search query that is executed in the database and the result from it are stored in memory.

The return from this method is recordset as well. The difference between this recordset and the one from the browse​ method is that this method is doing immediate query to the database and retrieves the data for the selected records, which means when a field is accessed, the value is taken from the memory instead of doing read in the database. The search method has a few additional optimization methods such as search_count​, search_read​ and search_fetch​.

Filtered

The filtered​ ​method as an argument accepts a function or a dot-separated sequence of field names. This method filters records on an already existing recordset, which is one of the differences compared to the previous two methods. The filtering in this method is done on python level and does not use database queries. 

Filtered Domain

Similarly to the filtered​ method, the filtering is done on the existing recordset. The difference is that in this case the argument is a domain, the same format as the one for search​, instead of a function. Depending on the complexity of the domain, the method may execute an actual search to do the proper filtering. However in most of the cases it filters the records in python by evaluating the domain. This is good in case the recordset is already fetched from the database and it is needed some additional filtering which is easier to express in a domain format.

Conclusion

To sum up, the browse​ method is used when there is list of IDs​ but we need a recordset for more convenient handling in the rest of the codebase. 
In case we have some parameters on base of which we need to query the database and get recordset then search​ method is the one that should be used. 
However, if we already have the recordset and need to do some additional filtering on it the filtered​ and filtered_domain​ methods are the right choice. Which one of these methods needs to be used mostly depends on the conditions that need to apply. In case of a simpler condition filtered would be more convenient to use but in case the conditions are more complex can be easier to translate them in a domain format and use filtered_domain​.

These suggestions are based on the assumption that the amount of data handling is moderate. In case of complex domains and bigger amounts of data may need to be done additional evaluation which method would perform the best for such case.

Many2many and One2many fields in Odoo require a specific syntax for manipulating related data. The instructions mainly consist of 3 elements added in a tuple, where each of the elements has a special meaning.

The first element is an integer number ranging from 0 to 6. each corresponding to a different action. The associated actions for each numerical value are:

• 0: Create
• 1: Update
• 2: Delete
• 3: Unlink
• 4: Link
• 5: Clear
• 6: Set

The second element for Update​, Delete​ and Unlink​ is the ID​ of the record to which the action applies while for the rest of the actions: Create​, Clear​ and Set​ this element is with value 0​.

The third element for the first two actions (Create​ and Update​) is the values​ used to create or update the record. For the next four, this element can be left out. The last action Set​, requires a list of IDs​ as a third element. The IDs​ represent the related records. This command replaces the existing relations with the newly supplied list of records’ IDs​.

In addition, is the complete tuple for each action:

• Create: (0, 0, values)
• Update: (1, ID, values)
• Delete: (2, ID)
• Unlink: (3, ID)
• Link: (4, ID)
• Clear: (5)
• Set: (6, 0, IDs)

Knowing the logic for the elements in the tuple makes it much easier to understand how to create any action without memorizing the list of tuples. However, from version 15, Odoo made this even easier. Now there is a class helper Command​ that is creating the whole tuple. 

The commands for each action are listed below:

• Create:  Command.create(values)
• Update: Command.update(ID, values)
• Delete:  Command.delete(ID)
• Unlink: Command.unlink(ID)
• Link:  Command.link(ID)
• Clear: Command.clear()
• Set: Command.set(IDs)

Where values​ represent a dictionary of values, ID​ is an integer value of the record’s id in the database and IDs​ is a list of related records ids in the database.

As an example, we will try to modify the tags related to a sales order. Initially, the sales order has only one tag added to it. That tag is with ID​ 1​.

Create:

If the requirement is to add another tag to the sales order which is not presented in the database needs to be used the create​ command:

sale.write({tag_ids: [Command.create({"name": "Tag 2"})]})

this will create a new tag and will add it to the order.

Update:

In case the name of the newly added tag needs to be updated the update will look like this:

sale.write({tag_ids: [Command.update(2, {"name": "Updated Tag 2"})]})      

Delete:

If the new tag is not needed anymore and needs to be removed from the relation with the sale order but at the same time from the database as well should be used the delete​ command.

sale.write({tag_ids: [Command.delete(2)]})

Unlink:

If the requirement was only to remove the tag from the sales order but still to be available in the database then the command unlink​would be the right one.

sale.write({tag_ids: [Command.unlink(2)]})      

Link:

If the tag with ID 3 that already exists in the database needs to be added to the sale order, then link​ is the correct command to use.

sale.write({tag_ids: [Command.link(3)]})

Clear:

In case the tags are not needed in the order and need to be removed from it, instead of going over the whole list and using unlink​ it can be done at once with the clear​ command.

sale.clear({tag_ids: [Command.clear()]})

Set:

The last case is when the current tags, with ID​ 1​ and 3​, which are already added to the order need to be replaced with tags, with ID​ 4​ and 5​, which are in the database but not related to the order.

sale.write({tag_ids: [Command.set([4, 5])]})

The end result after this command will be sales order with tags with IDs​ 4​ and 5​.

In case the content in a Char​ field needs to be split into multiple lines and represented like that in the view the new line character \n​ or HTML line break <br>​ tag are not supported in this type of field.

To be able to split the content into multiple lines the Text​ field needs to be used for the new line character \n​ while the <br>​ element is accepted in the HTML field.

The sequence of loading the views in Odoo is critical in the inheritance mechanism. The changes in the views are always applied following their order by priority​ and ID​. This means the views with the same priority will always be ordered by the ID​ that they have in the database. This makes the order of installing the modules in the database important for properly loading the views. In general, this is a problematic approach because not always we can have control over the sequence the modules are installed, especially when the system has multiple external modules from different sources. Basically, that is why sometimes some view modifications can work in some instances while failing in others.

In order to have more control over the sequence of loading the views in the system it is added priority​ field. Setting up the right value in this field can prevent many of the issues related to inheritance.

The value for the priority​ field mainly depends on three key factors:

• The view that needs to be inherited,
• The existing inheritance that the base view has
• The requirements for the new view

In most of the cases having the biggest priority for the new view can be the right choice, however, there are cases when this is not the best option. Therefore it is always important to do a detailed analysis of the original view and its existing inheritance and on base of that to decide where to insert the new view in the process.

A common issue with view inheritance is when an element from the base view is removed in one of its inherited views while in the new view, this element is used as a position attribute. In this case, if the new view is added with the biggest priority​ value the server will start to complain because the element is removed from the base view before the changes for the new view are applied.

The priority of a new view can be set in the following way:

<odoo>
    <record id="view_order_form" model="ir.ui.view">
        <field name="model">sale.order</field>
        <field name="inherit_id" ref="sale.view_order_form"/>
		<field name="priority">18</field>
        <field name="arch" type="xml">
            <!-- Here goes the customization part -->
        </field>
    </record>
</odoo>

The same things related to priority apply when working with QWeb templates. The priority​ value for a new QWeb templates can be set as shown in the example below:

<odoo>
	<template id="products_description" inherit_id="website_sale.products" priority="55">
	    ​<!-- Here goes the customization part -->
    </template>
</odoo>

The priority​ of a view can be updated from the UI using the "Views" menu in Settings or "Edit View" option in Developer Mode. The label for the priority​ field is "Sequence".

​TransientModel​ is a model super-class that stores data in the database temporarily and it is automatically cleaned up on a defined period of time.

The scheduled action to clean up the database, including the TransientModel​’s data is named "Base: Auto-vacuum internal data" and it can be found at Settings > Technical > Automation > Scheduled Actions​. The default interval for running is once per day.

From a security perspective, all users can create new records of a TransientModel​, however, they can access only the records that they have created, except for the superuser, which can access all records. Also, when using this class should be taken into consideration that Many2one relations are not allowed with a non-transient model.

The TransientModel​ class is mainly used when working with wizards and configuration settings, although it can be useful in a few other cases. In general, the model can be taken into consideration when there is a need to temporarily store data in the database which is essential only for the duration of a user's interaction with the system and can be removed after the interaction is finished.

Understanding how the security system works in Odoo is crucial for effectively configuring user permissions and comprehending why certain data may or may not be visible to users within the system. This article provides an in-depth analysis of the security system in Odoo starting with users, groups, and element and data restrictions. 

Users

To better understand the security system in Odoo, we can visualize it as a series of interconnected layers that collectively create a comprehensive security solution.

At the core of the security system is the user layer. Each user is a fundamental component that controls the level of access and privileges for a particular visitor. Every visitor to the system has a corresponding user profile. Visitors who are not logged in are typically assigned to the public user profile. The user's role in the system is defined within their profile, where can be assigned different types of security groups for the user.

A user can access the system by logging in using a standard username and password mechanism. Additionally, for enhanced security, a two-factor authentication process is available.

Groups

The next layer in the security system is known as "Groups," which serve as a bridge between users and the access limitations defined for specific application’s elements or data. Essentially, groups correspond to roles that can be assigned to employees within the system.

Groups in Odoo are structured in a hierarchical manner, which allows the nesting of multiple groups within one another. When a user is assigned to a particular group, they will inherit any related groups as well

For example, in the Sales module, there are three groups created for different levels of access. The first one, "Sales / User: Own Documents Only," is the lowest level and is designed for users with the lowest access rights. The second group, "Sales / User: All Documents," is intended to provide more broad access rights and includes the first group as an inherited group. Finally, the third group, "Sales / Administrator," has the most extensive permissions within the sales application and has the "Sales / User: All Documents" group as an inherited group.

1. Sales / User: Own Documents Only
2. Sales / User: All Documents
3. Sales / Administrator

So If a user is assigned to the first group, "Sales / User: Own Documents Only," they will only have access to that group within the system. However, if they are assigned to the second group, "Sales / User: All Documents," they will automatically inherit the first group as well. Similarly, if a user is assigned to the third group, "Sales / Administrator," the system will automatically assign them to both the first and second groups.

If a group has inherited groups they can be found in the "Inherited" tab of the group’s form view. Within the group form view, also can be found any related menus, views, access rights or record rules assigned to the group as well as any related users. This information can help to understand the level of security access that the group has in the system.

In Odoo, every group can be assigned to multiple users, and conversely, one user can be assigned to multiple groups which allows for flexible management of access rights.

Element Restrictions

Groups are an essential part of the access control system, but they cannot act on their own. They need to be linked to a component in the next layer to fully exercise their power. This layer contains two types of restrictions: 

• Element restrictions
• Data restrictions

They are designed to limit users' access to specific elements and data in the system.

Element restrictions are mainly defined in the codebase and can limit the view of buttons, fields, menus, and even entire views can be assigned to a group. This means that only users who are members of the particular group will be able to see that element. For example, only "Sales / Administrator" group may be able to view “Unlock” button in the Sales form view or the “Reporting” menu in the Sales application. Although these types of restrictions are usually defined in the codebase, they can be set from the UI as well, in the menus and views sections.

Data Restrictions

The second type of restriction is related to data models and is used to limit the user access to only the data that they have been granted permission to view, based on their assigned access groups. This type of restriction involves two layers of data control:

• Access Rights
• Record Rules.

Access Rights

Access Rights are responsible for the general control of the data stored in the data model. They define whether a user can read/write/create or delete the data related to that model. When defining access rights, it is enough to use the lowest level group, which will then be inherited by other groups. This means that other groups will also have the same access rights.

For instance, users with groups "Sales/Administrator" and "Sales/User: Own Documents Only" will both have the rights to read, create, write, and delete although the access rights are defined only for "Sales/User: Own Documents Only". However, if we take a look into the access rights defined for the “Public” group we can see that most of them have only read permissions because the group is expected to have minimal permissions in the system.

It is crucial to define access rights for each data model and assign appropriate groups to each. While it is possible to define access rights without a group, it is not recommended, especially for models holding sensitive data, as it would make the data accessible to anyone without any restrictions. It is always best to assign a group to every access right and give the minimum required rights.

Record Rules

While Access Rights are applied as a general rule for the entire data in the model, Record Rules filter the data at a more granular level. The Record Rules layer is designed to filter the data in the model based on predefined filters and to show only what a user should be able to see.

For example, let's consider the Sales groups again. A user with the group "Sales/User: Own Documents Only" can only see the sales orders where it is assigned as a salesperson, while a user with the group "Sales/User: All Documents" can see all sales orders in the system. To achieve this, there are two record rules defined.

The first rule is "Personal Orders," which is assigned to the "Sales/User: Own Documents Only" group. The domain in this rule is defined in such a way that records are filtered by the user who is assigned as a salesperson to the order. So the user can see only the orders to which they are assigned as a salesperson as well as all orders with an undefined salesperson.

The second rule is "All Orders," and as the name suggests, nothing is filtered from the records, so all orders can be seen by the users with the "Sales/User: All Documents" group.

Record Rules also have the option to limit different permissions, such as read, create, write, and delete. There may be cases where a user has the right to see the order but cannot perform any other actions on it. For example, “Portal” users can see their own orders, can edit them and remove them but they can not create a new order, so the order needs to be created for them by another user in the system.

If a group is not assigned to a rule, then the rule is considered a global rule and applies to all users. Global rules are mainly used to restrict data between different companies. For example, in the "Sales Order multi-company" rule, users can only see the orders created for the companies they are assigned to.

It is important to understand that global record rules are strict restrictions and cannot be overridden. On the other hand, record rules assigned to groups can further restrict global rules but can also be relaxed by additional group rules. This means that for a user to see a record, all global rules must be met, while for rules assigned to a group, at least one of the rules needs to be met. So, Record Rules apply to all users in that group, but can be extended by additional rules assigned to different groups.

Returning to the Sales example, users with the "Sales / User: All Documents" group can see all documents, despite also having the "Sales / User: Own Documents Only" group, because the record rule "All Orders" extends the rule "Personal Orders" with an additional domain that allows viewing all orders in the system.

 Conclusion

Every visitor is assigned to a user who is assigned to access groups that are related to both element and data restrictions. Element restrictions control what elements the user can see, such as buttons, fields, views, and menus, while data restrictions limit what data the user can access in the system. There are two layers of data control: Access Rights and Record Rules. Access Rights are responsible for general data control in the data model, while Record Rules filter data at a more granular level.

If a group is not assigned to a rule, the rule is considered a global rule and applies to all users. Global record rules are strict and cannot be overridden, while record rules assigned to groups can further restrict global rules but can also be relaxed by additional group rules.