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.
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.
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?
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.
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.)
Of course if you do not care about translations, you can just delete them.
This should work also.
It is not really needed to update the module of the translation table but it will avoid unnecessary delete/create.
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.