# Handling xml records in merging modules

**URL:** https://discuss.tryton.org/t/handling-xml-records-in-merging-modules/8531
**Category:** Developer
**Created:** [April 26, 2025, 5:43pm UTC](https://discuss.tryton.org/t/handling-xml-records-in-merging-modules/8531 "2025-04-26T17:43:31Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![jonl](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/jonl/32/1126_2.png) [@jonl](https://discuss.tryton.org/u/jonl)
#### Post date: [April 26, 2025, 5:43pm UTC](https://discuss.tryton.org/t/handling-xml-records-in-merging-modules/8531/1 "2025-04-26T17:43:32Z")

</div>

My installation relies on some legacy third-party modules that are no longer supported by those third parties. I want to remove those dependencies by migrating their functionality into my module.

How should I handle the xml-generated records from those removed modules?

I have tried (1) cleaning out the third-party .xml files of their records, (2) updating the database on that third-party module (so as to remove the records), (3) adding the xml to my module and updating the database on my module (to create the records), and (4) checking in the third-party module for any references based on `ir.model.data` or Pyson Id, which need to be re-pointed to the instances created by my module.

The problem I’ve run into is that removing the records from the third-party .xml and updating the database does not reliably remove the records. One understandable case was an `ir.user` instance, where the user was pointed to by Many2Ones of other models. (I.e., `ondelete='RESTRICT'` applied.) I have also encountered it with a `menuitem` and I’m not sure why it would happen there.

I would appreciate any advice as to how I should deal with these records.

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 28, 2025, 9:54am UTC](https://discuss.tryton.org/t/handling-xml-records-in-merging-modules/8531/2 "2025-04-28T09:54:47Z")

</div>

I think the simplest way is to run a SQL query that update the `module` value of the table `ir_model_data` to change from legacy module to the new module.  
Even if not every records are redefined in the new module, the process will clean up those former records.

---

<div class="post-metadata">

### Author: ![jonl](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/jonl/32/1126_2.png) [@jonl](https://discuss.tryton.org/u/jonl)
#### Post date: [May 1, 2025, 4:05pm UTC](https://discuss.tryton.org/t/handling-xml-records-in-merging-modules/8531/3 "2025-05-01T16:05:56Z")

</div>

In addition to updating the `module` column `ir_model_data`, I’ve found that I also need to update the `module` column of `ir_ui_view`. With that done, it seems to be working. But it makes me nervous that I am missing something else.

My plan is to check each type of model created by the removed module’s `xml`, and update its `module` column if it has one.

Does this seem reasonable, or is there a better way?

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [May 1, 2025, 5:14pm UTC](https://discuss.tryton.org/t/handling-xml-records-in-merging-modules/8531/4 "2025-05-01T17:14:38Z")

</div>

Indeed looking at the database schema of last version (which include foreign key constraint on `ir_module`) and to be complete, you can also update the `module` column of tables `ir_action_report`, `ir_model_field`, `ir_model`, `ir_translation`, `ir_ui_icon`.

---

<div class="post-metadata">

### Author: ![jonl](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/jonl/32/1126_2.png) [@jonl](https://discuss.tryton.org/u/jonl)
#### Post date: [May 1, 2025, 7:07pm UTC](https://discuss.tryton.org/t/handling-xml-records-in-merging-modules/8531/5 "2025-05-01T19:07:14Z")

</div>

Thank you.

Do you have any advice for handling `ir_translation`? The module being removed has some `.po` files, so update of `ir_translation` modifies some rows.

I see two options, and am hoping for some guidance between them.

First, because our installation using English only, I would be happy simply losing the translations (i.e., deleting the rows from the table).

Alternatively, I suppose I could add these files to a `locale` folder of my module (and merging with `.po` files if there are additional modules being removed that have name clashes).

Any suggestion of which way to go?

(I feel I should be extra cautious because direct SQL edits are not something I do regularly, for fear of breaking something low-level in Tryton’s system.)

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [May 1, 2025, 9:58pm UTC](https://discuss.tryton.org/t/handling-xml-records-in-merging-modules/8531/6 "2025-05-01T21:58:06Z")

</div>

> [@jonl](#):
>
> First, because our installation using English only, I would be happy simply losing the translations (i.e., deleting the rows from the table).

Of course if you do not care about translations, you can just delete them.

> [@jonl](#):
>
> Alternatively, I suppose I could add these files to a `locale` folder of my module (and merging with `.po` files if there are additional modules being removed that have name clashes).

This should work also.  
It is not really needed to update the module of the translation table but it will avoid unnecessary delete/create.

> [@jonl](#):
>
> (I feel I should be extra cautious because direct SQL edits are not something I do regularly, for fear of breaking something low-level in Tryton’s system.)

I would suggest to write the SQL queries in a file and run and test them on a copy of the database.  
Once you are confident there are not issue, you can run it on production database but after having backup the data. I would also keep the backup for a while in case you need them.
