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.

Every website developed with Odoo comes by default with a publicly available page that lists all installed addons in the system. Here are two methods how to hide this page:

1. Deactivating the Template for the Page:
   This approach hides all information on the page, displaying an empty page ​    when visitors attempt to access the URL.

• The simplest way to disable the template is from the "Customize" tab in Edit Mode.
  Once the page is opened in edit mode the toggle for "Odoo Information" can be found in the "Customize" tab. By turning the toggle to Off the template for the page will be disabled.
  
• Disable the template "Show Odoo Information" from the Technical Menu under the User Interface section: 
  Settings > Technical Menu > User Interface > Views.
  The view can be disabled by turning off the "Active" toggle.

2. Disabling the Controller for the URL /website/info​:
    This change ensures that when visitors try to access the URL,
    a 404(Not Found) Page​ will be displayed.

• Create a 404 redirect by navigating to:
  Website > Configuration > Redirects.
• Configure the redirect action as 404 Not Found​ and set the URL From​ as /website/info.

Additionally, to prevent the page from being indexed by search engines, the Robots.txt​ file needs to be updated with a new rule: "Disallow: /website/info". This can be accomplished by going to:
Website > Configuration > Settings > SEO > Edit Robots.txt.

The Developer Mode is a powerful tool in Odoo that provides access to a range of settings and options for both developers and admin users. This feature is crucial for configuring and maintaining the system properly. In this article, we will explore the Developer Mode from an admin user’s perspective and highlight the various features and settings it enables.

Activation

There are multiple ways to activate the Developer Mode in Odoo:

1. The first option is from the Developer Tools section which is located at the bottom of the main Settings page. This section provides several Developer Mode options. The first option is most suitable for non-technical users, while the other two are aimed more towards developers.
2. Another way to activate the Developer Mode is by adding the attribute “debug=1” to the URL.
3. Also, there are browser extensions for Chrome and Firefox that can be used to activate the Developer Mode.

Personally, I prefer the last option as it is the most convenient and efficient for me.

Features

The features that the Developer Mode provides for admin users can be divided into two main groups:

• Configuration settings and
• Data overview and modification

Configuration Settings

When the Developer Mode is activated in Odoo, the user gains access to a range of system configuration options. These settings are located under the Configuration menu in each module or in the general configuration options available in the Technical menu within the main settings page.

To provide a better understanding of the types of configuration options available in this mode, let’s review a few examples:

• In the Sales module, the configuration for Activity Types is only accessible in Developer Mode.
• Setting up Tax Groups in the Invoicing/Accounting module can be done only in Developer Mode.
• In the Technical menu, which is only available in this mode, there are multiple configuration options such as: 
• • Setting up Outgoing and Incoming email servers
  • Creating or modifying email and SMS templates
  • Creating or updating scheduled actions that will be executed on a predefined period of time
  • Configuring the System Parameters, some of these parameters are available for editing in a more user-friendly format from other parts of the system, while some of them can only be set from this section.
• The Translation settings are also only available under Developer Mode. Within this menu, users can activate/deactivate different languages in the system, import new translations, and export existing ones.
• Also in the User page, the Technical groups can only be set when Developer Mode is activated.

Data overview and modification

Another significant benefit of this mode is the access and overview of important data in the system. This contributes to an easier understanding of the whole system and a more manageable system directly from the user interface. To make it easier to comprehend, the data available through the Developer Mode, can be divided into two main categories:

• Technical data
• Functional data

Technical data

Technical data refers to the data that is crucial for the proper functioning of the system, and it can be accessed under the Technical menu. Some of the most important technical data that can be accessed are:

• Models: It provides an overview of the data models defined in the system. For each model can be found information about its attributes, related fields, access rights, record rules, and views.
• Fields: This view lists all the fields defined in the system. It is particularly helpful when the name of the field is known, but the model is not. For each field can be found information about its related attributes.
• Views: It contains all the available XML views. For each view, can be found information about its attributes as well as the full definition of it. Under the view definition, are defined all the fields that need to be shown in the view, their placement in the view as well as some additional attributes, which introduce different rules for the elements in the view, for example, they can make a field required, visible or hidden, read-only or editable, etc.
• Actions: They define the behavior of the system in response to the user’s actions. In Odoo there are a few different types of actions: Window Actions, Server Actions, Client Actions, URL Actions, Report Actions, and Automated Actions
• Menus: All the menus defined in the system can be found in this view.
• Access Rights and Record rules: These are an essential part of the security system in Odoo and ensure that each user can only see the data that corresponds to their profile.

It is important to note that the Models and Fields cannot be edited from the user interface, while the changes done to the Views, Actions, and Menus might be overridden when the module is updated. However, the Access Rights and Record Rules can be edited, and their updates will be permanent in most cases.

Additionally, technical data is also available for each field in the view. This means that users can examine each field directly in the view and review its basic information. This feature is useful when working on changes in the view and requiring information for a field, such as its technical name, type, model, relational model, context, and more. Users can access this information for each field by hovering over the small question mark symbols displayed on each of the fields.

Functional Data

The functional data available in the Developer Mode includes data created by the users and the system as a result of user actions. Admin users can access multiple views to review important data in the system. Here are some examples of such data:

• Messages: This view lists all messages created in the system.
• Followers: This view provides a complete overview of all followers related to all models in the system.
• Emails: All sent and scheduled emails can be found here. However, it should be noted that if the email template used for the email is marked with the Auto Delete option, the email will be auto-deleted once sent.
• Activities: This view lists all activities created by the users in the system.
• Attachments: This view provides a list of all attachments in the system.
• Payment Transactions: This view can be found under the Configuration menu in the Invoicing/Accounting module and lists all online transactions in the system.

Furthermore, Developer Mode can also reveal different view elements, such as fields, tabs, and sections that are not normally visible in the user interface. For instance, the Signature tab in the sales menu is only visible in Developer Mode. This is usually the case with sensitive data that is not necessary for regular users to see, but it can be useful to have an overview of it for special cases.

Developer Mode Menu

In Developer Mode, a small bug icon appears at the right corner of the main menu, just before the Conversations icon. This menu contains various options, some of which are more technical and mainly used by developers, we will focus only on the options which are useful for admin users.

Most of these options display technical or functional data for a particular view, model or record. For example:

• Edit Action displays actions related to the particular view,
• View Fields lists all fields related to the view,
• View Access Rights and View Record Rules display access rights and security rules related to the particular model,
• Get View shows the full view in XML format,
• Edit View and Edit Search View display the views with all their attributes. The views can be edited from here, but the changes are usually overwritten when the module is updated.

Some of the functional data related to the particular record can be managed using this menu. Most of these options are available when the form view of the record is opened:

• Managed Filters shows all custom filters for the model and allows the creation or modification of existing ones.
• Set Defaults allows setting a default value for the model. For instance, if some values on the current record should be present on all future records, they can be set as default values, and the value will be automatically set whenever a new record is created.
• View Metadata displays basic system information for the record, such as its ID in the database, the date it was created, and who created it. It also displays who last edited the record and when. Additionally, if the record has an external XML ID attached to it, it will be shown here. No Update indicates if this record is protected from updates from external XML data, meaning that if the record is edited and the module is updated, the changes will not be overwritten.
• Managed Messages lists all messages related to the record. Each message can be edited or removed.
• Managed Attachments displays all attachments added to the record. Similar to messages, they can be edited or removed from here.

The final two options in the Developer Mode menu are Become Superuser and Leave Developer Mode.
The first option, as the name implies, grants the user Superuser status in the system. This means that all access and record rules are ignored for that user. This option is useful when troubleshooting access rights issues.
The second option, Leave Developer Mode, disables the Developer Mode. This can be achieved in a few different ways, such as using the button Deactivate Developer Mode in the Developer Tools section or by clicking on the browser extension while Developer Mode is activated or simply by setting the “debug” attribute to 0 or removing it from the URL.

Conclusion

Despite its technical-sounding name, developer mode in Odoo is a valuable tool for both developers and admin users. It is an essential feature to properly configure the system and later maintain it.

While this article covers only a brief overview of the many options available in Developer Mode, the intention was not to provide all options but to highlight the type of configuration options and data that are accessible through this mode. In order to create a general understanding of the data and options available with it and where they can be found.

When creating a new QWeb template in Odoo that is very similar to an existing one, which still needs to be left unchanged, there is no need to rewrite the whole code from the existing template. Instead, it is enough to inherit it with flag ​primary=True​ and to make the required changes for the new template.

For example, If a new report is needed in the Sale module, that is very similar to the existing one, but the existing one is still required as it is, the definition for the new report template should look like following:

<odoo>
    <template id="new_report_saleorder_document" inherit_id="sale.report_saleorder_document" primary="True">
        <!-- Here goes the customization part -->
    <template/>
</odoo>