[19.0][FIX] hr: cleanup obsolete hr.employee fields + apriori-renamed views#72
Closed
dnplkndll wants to merge 1 commit into
Closed
[19.0][FIX] hr: cleanup obsolete hr.employee fields + apriori-renamed views#72dnplkndll wants to merge 1 commit into
dnplkndll wants to merge 1 commit into
Conversation
9a73d06 to
53bd361
Compare
… views After the hr_contract → hr apriori merge, two classes of stale records linger and trip cross-cutting view validation later in the migration: 1. ir_model_fields rows + orphan ir_ui_view records for fields the 18.0 hr_contract module added to hr.employee that no longer exist in 19.0: contract_id, contract_ids, contract_warning, first_contract_date, vehicle (listed DEL in upgrade_analysis_work.txt as "# NOTHING TO DO"), plus contract_template_id, contract_type_id, contract_wage, contracts_count, is_in_contract (not flagged by the analyzer but verified stale via grep against all 19.0 hr* modules). 2. ir_ui_view records whose xml_ids were auto-renamed by openupgradelib (`<orig_name>_openupgrade_<id>`) during the merge to avoid xml_id collision. Two such views exist after the merge: res_config_settings_view_form_openupgrade_65293 and hr_departure_wizard_view_form_openupgrade_65294. Their arch_db still references 18.0-only xpath targets (e.g. //block[@name='employee_rights_setting_container']) and parents that 19.0 doesn't ship. Both classes manifest as a migration crash when l10n_ae's account_tax_report_data.xml triggers global view validation around module 217/608 — without this patch the migration fails with either "Field 'first_contract_date' does not exist in model 'hr.employee'" or "Element '<xpath expr=...>' cannot be located in parent view". Add two helpers in pre-migration: - cleanup_obsolete_hr_employee_fields(env) - cleanup_openupgrade_renamed_hr_views(env) Update upgrade_analysis_work.txt: the "# NOTHING TO DO" block for the DEL fields becomes "# DONE: stale ir_model_fields rows + orphan ir_ui_view records cleaned up in pre-migration".
53bd361 to
6d3132f
Compare
Author
|
Folded into #47 (19.0-fix-hr-null-write-date): both fixes edit hr/19.0.1.1/pre-migration.py at the same anchors, so gitaggregate could not auto-merge them separately. Combined into one branch with both |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Migration work on the ledoent/OpenUpgrade fork (internal review). Rebased onto current 19.0.
After the hr_contract → hr apriori merge, two classes of stale records
linger and trip cross-cutting view validation later in the migration:
ir_model_fields rows + orphan ir_ui_view records for fields the 18.0
hr_contract module added to hr.employee that no longer exist in 19.0:
contract_id, contract_ids, contract_warning, first_contract_date,
vehicle (listed DEL in upgrade_analysis_work.txt as "# NOTHING TO DO"),
plus contract_template_id, contract_type_id, contract_wage,
contracts_count, is_in_contract (not flagged by the analyzer but
verified stale via grep against all 19.0 hr* modules).
ir_ui_view records whose xml_ids were auto-renamed by openupgradelib
(
<orig_name>_openupgrade_<id>) during the merge to avoid xml_idcollision. Two such views exist after the merge:
res_config_settings_view_form_openupgrade_65293 and
hr_departure_wizard_view_form_openupgrade_65294. Their arch_db still
references 18.0-only xpath targets (e.g. //block[@name='employee_rights_setting_container'])
and parents that 19.0 doesn't ship.
Both classes manifest as a migration crash when l10n_ae's
account_tax_report_data.xml triggers global view validation around
module 217/608 — without this patch the migration fails with either
"Field 'first_contract_date' does not exist in model 'hr.employee'"
or "Element '' cannot be located in parent view".
Add two helpers in pre-migration:
Update upgrade_analysis_work.txt: the "# NOTHING TO DO" block for the
DEL fields becomes "# DONE: stale ir_model_fields rows + orphan
ir_ui_view records cleaned up in pre-migration".