odoo
[FIX] Preserve all translated fields on v16 migration
Currently, the upgrade process preserves translations only for Odoo CE+EE fields. However, databases usually have more modules (or even custom fields) and those translations get lost when upgrading to Odoo 16.
With this script, all translated fields will inherit their translations in all languages. Since it is executed in the pre phase of base, it should be able to still find the ir_translation table.
@moduon MT-7120
However, databases usually have more modules (or even custom fields) and those translations get lost when upgrading to Odoo 16.
The table is renamed to _ir_translation and kept always. What translations are you trying to keep? Only entries with type='code' are cleaned before renaming the table.
After a migration, you can see an upgrade report like this:
It specifies that migrations may be wrong. However, in reality, all those are wrong because only the base language (usually en_US) is migrated.
With this script, all langs are always migrated in all fields (declared by Odoo or not). Still, something may be wrong; but at least, most problems get auto-fixed now.
Yes, you need to use _get_translation_upgrade_queries on your side (via an upgrade script) when updating the custom modules (with custom code available) on your upgraded DB.
That's the same mechanism we use in the standard upgrade script. We cannot do this for custom fields because we don't know if a field has a special translate= method. This option comes via code and we do not have the custom code. There are two standard options xml_translate and html_translate, but there could be even a custom translate.
What you could do is something like (beware: not tested!)
for model in your_custom_models:
if model._auto and not model._abstract:
for field in model._fields.values():
if field.store and field.translate:
migrate, cleanup = _get_translation_upgrade_queries(cr, field)
# run the queries in migrate, and cleanup
Side node: when _get_translation_upgrade_queries was introduced this repo didn't exist thus the way to share the queries with the community was via the main odoo repo.
IIUC there shouldn't be an incompatibility between this PR and your suggestion, right? 🤔
This PR only improves the default value for those fields. If there's more magic involved, then you can still do that and get to the appropriate fix.
@yajo
IIUC there shouldn't be an incompatibility between this PR and your suggestion, right? 🤔
This change is risky because it will interfere with all the battle tested machinery of the translations in 15->16 upgrade. Including PO loading, noupdate flags, etc. Also for specific scripts of some clients.
This PR only improves the default value for those fields. If there's more magic involved, then you can still do that and get to the appropriate fix.
If you want to contribute an improvement I think it would be better to add something that could be used directly in end- scripts for custom code (in specific.py). That way the community could have a simpler alternative than figuring out how to use _get_translation_upgrade_queries. We could even add a reference to it in the upgrade report (like in the example picture you sent before).
@KangOl could you give some insight here please?
Could you please rebase your fork's branch in the latest master of this repo? The CIs are all red due to this.
I didn't notice this was broken. CI is fixed now. Could you review again please?