Why are data records introduced by a module removed when I update that module in Odoo 10?

Question

I have just restored a database in Odoo 10. I have even copied the source code of the instance and the virtualenv from the server to preserve the environment. The restoration worked OK, I can work with the database.

But I want to update all the modules, and I get some critical errors when updating some of them. For example, when I try to update only one module (l10n_es), I get this error:

odoo.addons.base.ir.ir_model: Deleting 24@account.account.type (l10n_es.account_type_ingresos_neto) odoo.sql_db: bad query: DELETE FROM account_account_type WHERE id IN (24) ... NotNullViolation: null value in column "user_type_id" violates not-null constraint DETAIL: Failing row contains (712, null, other, Beneficios en activos financieros disponibles para la venta, 1, f, 1, 1, null, 900000000, 2018-02-01 09:28:54.453977, null, 2018-02-01 09:28:54.453977, null, f). CONTEXT: SQL statement "UPDATE ONLY "public"."account_account" SET "user_type_id" = NULL WHERE $1 OPERATOR(pg_catalog.=) "user_type_id""

Before doing the update, I made the following queries:

SELECT * FROM ir_model_data WHERE model='account.account.type' AND res_id=24;

Which returns the following:

  id  | create_uid |        create_date         |         write_date         | write_uid | noupdate |            name            |      date_init      |     date_update     | module  |        model         | res_id 
------+------------+----------------------------+----------------------------+-----------+----------+----------------------------+---------------------+---------------------+---------+----------------------+--------
 7850 |          1 | 2018-02-01 09:19:01.412377 | 2021-02-08 15:28:04.013464 |         1 | f        | account_type_ingresos_neto | 2018-02-01 09:19:01 | 2021-02-08 15:28:04 | l10n_es | account.account.type |     24

And then I execute this:

SELECT * FROM account_account_type WHERE id=24;

Which returns:

 id | create_uid |           name           | write_uid | note |         write_date         |        create_date         | include_initial_balance | type  
----+------------+--------------------------+-----------+------+----------------------------+----------------------------+-------------------------+-------
 24 |          1 | Ingresos patrimonio neto |         1 |      | 2021-02-08 15:28:04.013464 | 2018-02-01 09:19:01.412377 | t                       | other

With these two queries I confirmed that, in the database, there is an account type with ID 24 named Ingresos patrimonio neto, which has the External XML ID l10n_es.account_type_ingresos_neto.

If I check the code of the instance, the module l10n_es has a folder data where there is a file named account_type.xml. This file is called by the __manifest__.py and creates the record:

<record id="account_type_ingresos_neto" model="account.account.type">
    <field name="name">Ingresos patrimonio neto</field>
    <field name="include_initial_balance" eval="True"/>
</record>

So, I cannot understand why when I update the module, it removes this record (this fact produces the error):

odoo.addons.base.ir.ir_model: Deleting 24@account.account.type (l10n_es.account_type_ingresos_neto)

I thought that when a module was updated, it removed the records (introduced by it) whose External XML ID (in database) was not in the code anymore, as this answer explains: Why is the account module upgrade unlinking records on some tables?

Why is the module deleting the existing records with still existing XML IDs when I update it?

Answer 1

DEFINITIVE ANSWER

Finally I realized that I had the guilty module (l10n_es) repeated twice in the Odoo instance. It was in two different paths called by addons_path parameter.

In the case of l10n_es for version 10.0, Odoo Community Association has the module in two different repositories: OCB and l10n-spain. This is not the case of the later versions of Odoo, in which OCA uses OCB l10n_es and does not create its own l10n_es.

OLD ANSWER

The problem on changing the module or the name in the ir_model_data (the solution of the link referenced in the question) is that those records we change can be duplicated on module update.

My solution was to execute this query on the conflictive records:

UPDATE ir_model_data SET noupdate=TRUE WHERE module='l10n_es' AND name='account_type_ingresos_neto';

This way, the records are not deleted when updating the module and therefore, other records (which have them set as foreign key) do not raise a not null error.

In fact, I think that the module l10n_es should change the <data> tag to <data noupdate="1"> in some XML files which load new records.

But actually, I don't know if this is the best solution.