When the data loading is repeated, existing records from the previous run are rewritten.

This is important to keep in mind: it means that upgrading a module will overwrite any manual changes that might have been made to the data. Notably, if views were modified with customizations, those changes will be lost with the next module upgrade. The correct procedure is to instead create inherited views for the changes we need, as discussed in the Chapter 3, Inheritance – Extending Existing Applications.

This overwrite behavior is the default, but it can be changed, so that when an already created record is loaded again no change is made to it. This is done by adding to the <data> element a noupdate="1" attribute. With this, its records will be created the first time they are loaded, and in subsequent module upgrades nothing will be done to them.

This allows for manually made customizations to be safe from module upgrades. It is often used with record access rules, allowing them to be adapted to implementation specific needs.

It is also possible to have more than one <data> section in the same XML file. We can take advantage of this to have a data set with noupdate="1" and another with noupdate="0".

The noupdate flag is stored in the External Identifier information for each record. It's possible to edit it directly using the External Identifier form available in the Technical menu, with the Non Updatable checkbox.

Each <record> element has two basic attributes, id and model, and contains <field> elements assigning values to each column. As mentioned before, the id attribute corresponds to the record's External ID and the model to the target model where the record will be written. The <field> elements have available a few different ways to assign values. Let's look at them in detail.

The <record> element defines a data record, and contains <field> elements to set values on each field.

The name attribute of the field element identifies the field to be written.

The value to write is the element content: the text between the field's opening and closing tag. In general this is also suitable to set non-text values: for Booleans, "0"/ "1" or "False"/"True" values will be correctly converted; for dates and datetimes, strings with "YYYY-MM-DD" and "YYYY-MM-DD HH:MI:SS" will be converted properly.

A more advanced alternative to define a field value is using the eval attribute instead. This evaluates a Python expression and assigns the resulting value to the field.

The expression is evaluated in a context that, besides Python built-ins, also has some additional identifiers available. Let's have a look at them.

To handle dates, the following modules are available: time, datetime, timedelta and relativedelta. They allow calculating date values, something that is frequently used in demonstration (and test) data. For example, to set a value to yesterday we would use:

<field name="expiration_date"
   eval="(datetime.now() + timedelta(-1)).strftime('%Y-%m-%d')" />

Also available in the evaluation context is the ref() function, used to translate an External ID into the corresponding database ID. This can be used to set values for relational fields. As an example, we have used it before to set the value for the user_id:

<field name="user_id" eval="ref('base.group_user')" />

The evaluation context also has a reference available to the current Model being written through obj. It can be used together with ref() to access values from other records. Here is an example from the Sales module:

<value model="sale.order"
  eval="obj(ref('test_order_1')).amount_total" />

We have just seen how to set a value on a many-to-one relation field, such as user_id, using the eval attribute with a ref() function. But there is a simpler way.

The <field> element also has a ref attribute to set the value for a many-to-one field using an External ID. Using it, we can set the value for user_id using just:

<field name="user_id" ref="base.group_user" />

For one-to-many and many-to-many fields, a list of related IDs is expected, so a different syntax is needed, and Odoo provides a special syntax to write on this type of fields.

The following example, taken from the Fleet app, replaces the list of related records of a tag_ids field:

<field name="tag_ids"
  eval="[(6,0,   
    [ref('vehicle_tag_leasing'),
    ref('fleet.vehicle_tag_compact'),
    ref('fleet.vehicle_tag_senior')]
)]" />

To write on a to many-field we use a list of triples. Each triple is a write command that does different things according to the code used:

The underscore symbol used above represents irrelevant values, usually filled with 0 or False.

If we go back to Chapter 2, Building Your First Odoo Application, we can find in the XML files elements other than <record>, such as <act_window> and <menuitem>.

These are convenient shortcuts for frequently used Models that can also be loaded using regular <record> elements. They load data into base Models supporting the user interface and will be explored in more detail later, in Chapter 6, Views - Designing the User Interface.

For reference, so that we can better understand XML files we may encounter in existing modules, the following shortcut elements are available with the corresponding Models they load data into:

Until now we have seen how to add or update data using XML files. But XML files also allow performing other types of actions, sometimes needed to set up data. In particular, they are capable in deleting the data, execute arbitrary model methods, and trigger workflow events.

<delete
   model="ir.rule"
   search="[('id','=',ref('todo_app.todo_task_user_rule'))]"
/>

<delete model="ir.rule" id="todo_app.todo_task_user_rule" />

<function
  model="res.partner"
  name="create_membership_invoice"   
  eval="(ref('base.res_partner_2'),
    ref('membership_0'),
    {'amount':180})"
/>

<workflow model="sale.order"
          ref="sale_order_4"
          action="order_confirm" />