diff --git a/docsource/modules190-200.rst b/docsource/modules190-200.rst index 8da46d62bbc..f74f61fb650 100644 --- a/docsource/modules190-200.rst +++ b/docsource/modules190-200.rst @@ -404,7 +404,7 @@ Module coverage 19.0 -> 20.0 +---------------------------------------------------+----------------------+-------------------------------------------------+ | l10n_fr_facturx_chorus_pro | |No DB layout changes. | +---------------------------------------------------+----------------------+-------------------------------------------------+ -| l10n_fr_hr_holidays | | | +| l10n_fr_hr_holidays |Done | | +---------------------------------------------------+----------------------+-------------------------------------------------+ | |del| l10n_fr_hr_work_entry_holidays | | | +---------------------------------------------------+----------------------+-------------------------------------------------+ diff --git a/openupgrade_scripts/scripts/l10n_fr_hr_holidays/20.0.1.0/post-migration.py b/openupgrade_scripts/scripts/l10n_fr_hr_holidays/20.0.1.0/post-migration.py new file mode 100644 index 00000000000..13ed15f6f91 --- /dev/null +++ b/openupgrade_scripts/scripts/l10n_fr_hr_holidays/20.0.1.0/post-migration.py @@ -0,0 +1,40 @@ +# Copyright 2026 Don Kendall +# License AGPL-3.0 or later (https://www.gnu.org/licenses/agpl). + +from openupgradelib import openupgrade + +# hr_holidays leaves the source hr.leave.type id on the work entry type standing +# in for it, which is what makes this lookup possible at all. +_legacy_leave_type_id = openupgrade.get_legacy_name("hr_leave_type_id") + + +@openupgrade.migrate() +def migrate(env, version): + """Point the French reference leave type at its 20.0 stand-in. + + res.company.l10n_fr_reference_leave_type referenced hr.leave.type, which + 20.0 folds into hr.work.entry.type; the replacement is + l10n_fr_reference_work_entry_type. + + This lives here rather than with the rest of that fold in hr_holidays + because of load order: hr_holidays runs at module 234 of 563 and + l10n_fr_hr_holidays at 361, so when hr_holidays' post-migration runs the new + column does not exist yet. Its column_exists guard skipped the update + silently -- no error, no value, and the company's reference type quietly + lost. Doing it from the module that owns the column removes the ordering + question entirely. + """ + if not openupgrade.column_exists( + env.cr, "res_company", "l10n_fr_reference_leave_type" + ): + return + openupgrade.logged_query( + env.cr, + f""" + UPDATE res_company c + SET l10n_fr_reference_work_entry_type = wet.id + FROM hr_work_entry_type wet + WHERE wet.{_legacy_leave_type_id} = c.l10n_fr_reference_leave_type + AND c.l10n_fr_reference_work_entry_type IS NULL + """, + ) diff --git a/openupgrade_scripts/scripts/l10n_fr_hr_holidays/20.0.1.0/upgrade_analysis.txt b/openupgrade_scripts/scripts/l10n_fr_hr_holidays/20.0.1.0/upgrade_analysis.txt new file mode 100644 index 00000000000..b7a7a368dc9 --- /dev/null +++ b/openupgrade_scripts/scripts/l10n_fr_hr_holidays/20.0.1.0/upgrade_analysis.txt @@ -0,0 +1,5 @@ +---Models in module 'l10n_fr_hr_holidays'--- +---Fields in module 'l10n_fr_hr_holidays'--- +l10n_fr_hr_holidays / res.company / l10n_fr_reference_leave_type (many2one): DEL relation: hr.leave.type +l10n_fr_hr_holidays / res.company / l10n_fr_reference_work_entry_type (many2one): NEW relation: hr.work.entry.type, hasdefault: default +---XML records in module 'l10n_fr_hr_holidays'--- diff --git a/openupgrade_scripts/scripts/l10n_fr_hr_holidays/20.0.1.0/upgrade_analysis_work.txt b/openupgrade_scripts/scripts/l10n_fr_hr_holidays/20.0.1.0/upgrade_analysis_work.txt new file mode 100644 index 00000000000..e25d31d4988 --- /dev/null +++ b/openupgrade_scripts/scripts/l10n_fr_hr_holidays/20.0.1.0/upgrade_analysis_work.txt @@ -0,0 +1,10 @@ +---Models in module 'l10n_fr_hr_holidays'--- +---Fields in module 'l10n_fr_hr_holidays'--- +l10n_fr_hr_holidays / res.company / l10n_fr_reference_leave_type (many2one): DEL relation: hr.leave.type +# NOTHING TO DO: the column is left in place for database_cleanup +l10n_fr_hr_holidays / res.company / l10n_fr_reference_work_entry_type (many2one): NEW relation: hr.work.entry.type, hasdefault: default +# NOTHING TO DO: a new field whose default is falsy -- False, or an empty +# list -- so a NULL left on an existing row already means what the default +# would have written. The one flagged field whose default names a record, +# pos.config.default_product_id, has a script instead +---XML records in module 'l10n_fr_hr_holidays'---