Notes on upgrading from Tryton 4.0 to Tryton 4.2
written on Thursday, December 15, 2016
The Tryton developers released a new version of Tryton a few days ago. We try to keep up with the current stable version, so an upgrade is required. This posts lists the subtle changes that caused problems with our installation.
Before the upgrade
Custom and third-party modules
- Update dependencies to Tryton 4.2.
- Tryton 4.2 reworked the translation system which requires translation files
to be renamed. For all languages, rename the .po files as follows (See
- en_US.po → en.po
- de_DE.po → de.po
- Reports use English as fallback language in case no other language is defined. Due to the translation updates one needs to use en as fallback instead of en_US (See: issue5443).
The field vat_code was renamed to tax_identifier. Adapt to this change in case you are using this value in a report.
The full address of a party now includes the party name. In our case the party name is duplicated on reports and we decided to go with this minimal patch for the party module to restore the old behaviour.
The report generation is broken for parties when certain countries are used in the address record. The following patch fixes the issue for Tryton 4.2 (See: issue6111):
- Previous versions used <product_name(move.product.id, shipment.delivery_address.party.lang and shipment.delivery_address.party.lang.code or 'en_US')> in the report. This was changed to move.product.rec_name in the upstream delivery note report. Adapt accordingly in case you are using a custom delivery note report.
To get started, clone the running instance and test the upgrade with the clone. Our Tryton instance is installed in a virtual environment, so I started out by updating the version information in our Ansible role from 4.0 to 4.2. After that, Ansible can create the new virtual environment. Beware to upgrade all custom modules before this step as they need to depend on the new Tryton version.
Run pip freeze | grep "4.0" in the virtual environment to make sure no modules from 4.0 are lingering around.
In order to keep custom translations, one needs to convert them before performing the database upgrade. Connect to the database and update all translations:
Upgrading the database
After the translation updates we are ready to upgrade the database:
The database upgrade completed successfully.
A few problems popped up after the upgrade:
Until next time.