[17.0][OU-ADD] l10n_fr_hr_holidays: Migration scripts

[remi-filament]

Look for most accurate leave type to set in configuration parameter for this new module

[remi-filament]

Hi @hbrunn
As commented on #5533 (comment), this upgrade script for this new module is not run by OpenUpgrade.

I see the following in the logs :

2026-02-25 07:50:35,240 35968 INFO odoo17_l10n_fr odoo.modules.loading: Loading module l10n_fr_invoice_addr (42/42) 
2026-02-25 07:50:35,566 35968 INFO odoo17_l10n_fr odoo.modules.registry: module l10n_fr_invoice_addr: creating or updating database tables 
2026-02-25 07:50:35,707 35968 INFO odoo17_l10n_fr odoo.modules.loading: loading l10n_fr_invoice_addr/views/report_invoice.xml 
2026-02-25 07:50:35,769 35968 INFO odoo17_l10n_fr odoo.modules.loading: Module l10n_fr_invoice_addr loaded in 0.53s, 93 queries (+93 other) 
2026-02-25 07:50:35,769 35968 INFO odoo17_l10n_fr odoo.modules.loading: 42 modules loaded in 86.47s, 33191 queries (+33192 extra) 
2026-02-25 07:50:35,802 35968 INFO odoo17_l10n_fr odoo.modules.loading: loading 44 modules... 
2026-02-25 07:50:35,802 35968 INFO odoo17_l10n_fr odoo.modules.loading: Loading module account_payment_term (36/44) 
2026-02-25 07:50:35,991 35968 INFO odoo17_l10n_fr odoo.modules.registry: module account_payment_term: creating or updating database tables 
2026-02-25 07:50:36,231 35968 INFO odoo17_l10n_fr odoo.modules.loading: loading account_payment_term/views/account_payment_term_views.xml 
2026-02-25 07:50:36,289 35968 INFO odoo17_l10n_fr odoo.modules.loading: Module account_payment_term loaded in 0.49s, 52 queries (+52 other) 
2026-02-25 07:50:36,290 35968 INFO odoo17_l10n_fr odoo.modules.loading: Loading module l10n_fr_hr_holidays (43/44) 
2026-02-25 07:50:36,477 35968 INFO odoo17_l10n_fr odoo.modules.registry: module l10n_fr_hr_holidays: creating or updating database tables 
2026-02-25 07:50:36,647 35968 INFO odoo17_l10n_fr odoo.modules.loading: loading l10n_fr_hr_holidays/views/res_config_settings_views.xml 
2026-02-25 07:50:36,702 35968 INFO odoo17_l10n_fr odoo.modules.migration: module l10n_fr_hr_holidays: Running migration [17.0.1.0>] post-migration 
2026-02-25 07:50:36,741 35968 INFO odoo17_l10n_fr odoo.modules.loading: Module l10n_fr_hr_holidays loaded in 0.45s, 127 queries (+127 other) 
2026-02-25 07:50:36,741 35968 INFO odoo17_l10n_fr odoo.modules.loading: 44 modules loaded in 0.94s, 179 queries (+179 extra)

We can see that it ends loading the 42 modules present initially, then it goes through the 2 new modules account_payment_term and l10n_fr_hr_holidays.
It detects post-migration script for l10n_fr_hr_holidays (Running migration [17.0.1.0>] post-migration) but these are not run (when scripts are run for other modules, you ususally have a line with OpenUpgrade: base_vat: post-migration script called with version 16.0.1.0 which I do not have here.

Maybe I need to change the version number or trick something ?

[hbrunn]

hmm, 17. I don't even have a debug env for 17 any more. Start debugging in https://github.com/OCA/OpenUpgrade/blob/17.0/openupgrade_framework/odoo_patch/odoo/modules/migration.py#L18 to see why this doesn't run

[hbrunn]

or wait, that's a post-migration script, I don't think we guarantee running those. Please try if it does run a pre-migration script, if so, you'll have to bite the bullet and precreate the field to set the link with sql

[remi-filament]

Thanks for the pointer @hbrunn I found how to force use of post-migration script by adding no_version=True to migrate decorator !

[hbrunn]

ah right. might make sense to document that in https://github.com/OCA/OpenUpgrade/blob/documentation/docsource/080_migration_script_development.rst, no?

[remi-filament]

Yes it should probably be added in documentation, although I think it may not be needed on v18 at least.

I found only one other occurence of this no_version=True here :

OpenUpgrade/openupgrade_scripts/scripts/sale_project/14.0.1.0/pre-migration.py

Line 23 in 29925d6

@openupgrade.migrate(no_version=True)

where we were in the same case (sale_project is a new module split from sale_timesheet.

However on version 18.0 it seems to be working without having to add this parameter, as done for instance here :

OpenUpgrade/openupgrade_scripts/scripts/l10n_fr_account/18.0.2.2/post-migration.py

Line 24 in f12753e

@openupgrade.migrate()

I am not sure then if this is because it is not needed anymore on v18 or for any other reason ?

Maybe @pedrobaeza or @MiquelRForgeFlow or @legalsylvain or @StefanRijnhart can shed some light here ?

[pedrobaeza]

You need to use it when the module is new, no matter the version.

[remi-filament]

Thanks @pedrobaeza
What puzzled me was that it does not seem necessary for l10n_fr_account in v18.

I think I realized why : l10n_fr_account is not considered as new in v18 because it is in apriori.py in merged_modules from l10n_fr_fec and l10n_fr_invoice_addr which is called in base/pre-migration for renaming the modules, so it is not considered as a new module...

We should then consider adding it in documentation as pointed out here : #5539 (comment)
I looked at the documentation link you sent @hbrunn which seems very high level, I am not sure if such a technical point should be added there, though I did not find a more technical section where it should fit...

[pedrobaeza]

Yes, on merged modules, they are considered already installed, so they pass a version in the argument.