When passing a default value for a field via context​, you need to consider that this value can be passed on to models initially not planned for.

For example, when passing the product_qty​ as a default value in the manufacturing order, the value will propagate to the stock move as well, which may cause some unexpected issues, since it has the same field.

In such cases, the issue can be resolved by removing the default values from context, once they reach the initially intended model.

Understanding Routes in Odoo can be challenging. Here are three basics that may help to make sense of them:

1. Routes are just groups of rules
2. They help to organize and assign one or multiple rules to a product
3. Routes without a rule assigned to them don’t do much.

A default value for a field may not be set on the creation of a new record, even provided in the field definition

In many cases, the reason for that is an onchange​ method that is resetting the value for the field. Steps that can help in resolving the issue:

• Identify the method that is causing the issue by searching by the field’s name, and seeing where the field’s value is reset.
• Try to understand the current logic and how your change will affect it.
• Override the method using super​ and apply your custom logic

Bill control policy is the setting that defines at which point a Bill can be created for a product in a purchase order.

There are two available options:

• Ordered quantities
• Received quantities

The first option allows to create a bill for all ordered quantities right after the purchase order is confirmed, which means it will not make any difference if the products are received or no. While the second option allows to create a bill only for the received quantities, that is the default option when the module is installed.

This setting is per product and can be found in the Product Form View in the “Purchase" Tab.

The default value for each product is taken from the setting available in Purchase Configuration Page. This setting does not have direct influence on the purchase orders but instead on the default value for the newly created products. Which means in case there is old products that have different option selected already, that one will be still the relevant one for them in the purchase orders, unless it is manually changed.

To summarize , in case the business logic for bill control policy change, it is not enough only to update the setting in the purchase configuration page, but also all products that have the old setting need to be updated.

In some cases, there is a need to override the create​ method in Odoo and add additional logic to it. 

When overriding this method, the custom logic is triggered on each iteration of creating a new object.

 This means whenever a new object is created the extra code will be evaluated and applied.

In case when the additional logic is closely related to the object's data, this approach can be all right, since the codebase looks simpler and more clear.

However, in situations where some of the custom logic is repeating, especially when using database data, the logic will be executed n-times for n-objects, without any need for that.

In such cases should be used the decorator model_create_multi​. Adding this decorator to the create​ method allows the repeating code to be executed only once and applied to each object using a for​ loop.

It is important to mention that when using the model_create_multi​ decorator, the method receives a list of values while returns a list of newly created objects.

A very simple case to understand the need for this decorator is shown below:

@api.model_create_multi
def create(self, vals_list):
    round_precision = self.env['decimal.precision'].precision_get('Product Unit of Measure')
    for vals in vals_list:
		    vals["quantity"] = float_round(vals["quantity"], precision_digits=round_precision)
    return super().create(vals_list)
        

Without using the decorator the logic related to getting the value for round_precision​ will be executed every time a new object is created, which means for a batch of n-objects will be executed n-times.

But in our example, it will be executed only once and applied to all object values using the for​ loop.

When using many2many_tags​ widget, it is possible to define a background color for each of the tag values. For that to work the following steps need to be done:

• The related model needs to have an Integer type field where the color index will be stored, usually named color​.
• The color​ field needs to be added in the view using the widget color_picker​
• In the definition of the relational field in the XML view, when using the widget many2many_tags​, it needs to be set the option color_field​ with value the name of the color field previously defined.​
• The last step is optional, by default when a user selects a value, can edit the background color of the value's tag, however, it is possible to make the color not editable at this stage, by using the option no_edit_color​

Let’s review the steps above using as an example the relational many2many​ field tag_ids in the sale.order​ model related to the relational model crm.tag​​.

The model crm.tag​ there is a field color​ defined in the model definition as the following:

color = fields.Integer("Color")

The definition of the field in the XML view, using the widget color_picker​ looks like the following:

<field name="color" required="True" widget="color_picker"/>

Having this definition of the field makes it possible for every sales tag value defined in the system to be selected a color which later will be used as a background color for the tag.

Once the field is set up in the relational model the next step is when defining the related field tag_ids​ in the XML views to use the widget many2many_tags​ and add as an option the color_field​.

<field name="tag_ids" widget="many2many_tags" options="{'color_field': 'color'}"/>

This will add a background color for the selected tag values in the sales order. Also users will be able to change the color of the tags during the selection process. A possible issue with this change is that the color will be applied to all sales orders where the same value is used. In case the admin wants to keep the colors same as initially set, it is possible to disable the edit of the color at the moment of selection by using the option no_edit_color​ set to True​.

<field name="tag_ids" widget="many2many_tags" options="{'color_field': 'color', 'no_edit_color': true}"/>

In Odoo it is possible to change the color or text style of a column in a list view using the “decoration” attributes.

The syntax for them is decoration-<style>​ where the style can be one of the following options:

• Color: info​, warning​, danger​, muted​, primary​ and success​
• Text style: bf​ (bold) and it​ (italic)

The color that each of the color-styles represents can be seen in the image below:

These attributes, as most of the Odoo attributes in the views, accept as a value python-based condition. The style is displayed when the condition is evaluated as boolean True​. In case when the color need to be applied to the column without condition the value can be simply set to 1​ or True​

An example of using the attributes in the view is shown below:

<field name="state" decoration-success="state == 'posted'" decoration-info="state == 'draft'"/>

In case the attributes are used together with the attribute widget="badge"​ then the color will apply as a background color of the badge.

In Odoo it is really convenient to change the price of multiple products using the pricelist option. In this post we will go through the steps that are needed to make that happen.

At first would be need to enable the option “Advanced Price Rules” in the Sales configuration page, which can be found in Sales >> Configuration >> Settings​

Once that is done, open the pricelist page from Sales >> Products >> Pricelists​ and select an existing pricelist or create a new one.

The pricelist can be specific per company, country group or website. In our case we will assume that the pricelist is global for all products without any restriction.

In the “Price Rules” tab click on the button “Add a line” which will open a wizard as the one on the image:

Select the Computation​ method “DIscount” and in the Discount​ field set the value by which the price should be changed.

The important thing when setting this field is to take into consideration that if the price need to increase the value should be negative or in case of decrease it should be positive.

For example if the price need to increase for all products by 10% than the value in this field should be -10. In case the price for all products need to decrease by 10% the value should be 10.

For more complex pricing rules need to be used the option “Formula”, which still have the field Discount​ but additionally can be setup few more variables such as:

• Base On​:  The price field based on which the calculation will be done (Sales Price or Cost Price)
• Extra Fee​: Additional fixed fee added on the price calculated with the discount
• Rounding Method​: Decimal number representing the minimum non-zero value at the desired precision.
• Margins​: Minimum margin over the base price

The wizard with “Formula” options is shown in the image below:

The created pricelist can be assigned to a Customer, used in a Sales Order, or applied on the Website.