[dnplkndll]

hr.leave.type is gone in 20.0: hr_holidays now _inherits
hr.work.entry.type and declares the leave settings on it. Both models
existed in 19.0, so this is a merge and not a rename — it must not go in
apriori.renamed_models, which would have the analysis report the two as one
record.

The upgrade leaves the 76 hr_leave_type rows orphaned with their xml_ids
already deleted, and hr.leave / hr.leave.allocation still pointing at them
through the holiday_status_id they no longer use. 20.0 declares the
replacement work_entry_type_id required, so the upgrade reports it cannot add
the constraint and carries on with every leave and allocation unlinked from
its type.

Which work entry type stands in for each leave type

19.0's hr.leave.type already carried a work_entry_type_id — the pairing the
administrator configured — so it is honoured where unambiguous. On the seed:

	count	outcome
links to a work entry type of its own	46	keeps it
shares one with another leave type	12	oldest keeps it, rest get their own
no link at all	18	gets its own

20.0 has one record where 19.0 had two, so two leave types sharing one cannot
both keep it; whatever differs between them would have to be discarded. Giving
up the pairing loses less than giving up the leave type.

Fields with no counterpart

count_as and unit_of_measure are required on a work entry type and named
differently on a leave type, so they are mapped: time_type leave→absence
and other→working_time (the same two labels), request_unit hour→hour
and both day units→day, 20.0 having no half day for allocation. Both are set
only on records created here — a reused work entry type already carries them
from its work entry side, where they drive payroll.

code is the payroll reference and has no counterpart at all. A leave type that
shared a work entry type takes that one's code, being the code its time off was
actually paid under; one that had none gets a traceable placeholder and is
counted in a message, because nothing else would say so.

Not merge_models: by then nothing refers to hr.leave.type by name — the
model is absent from the 20.0 registry, so Odoo has already removed its
ir_model row and all nine dependent tables hold zero such rows — and calling
it fails rather than doing nothing.

Tested

openupgrade_scripts/scripts/hr_holidays/tests/ covers the three cases the
merge has to tell apart plus the mappings. 7 methods, run on the 585-module
seed; they caught is_leave being set, which is a 19.0 field 20.0 drops.

Draft until fork CI is green on this branch alone. Depends on #119 for the rest
of the analysis sweep.

AI-assisted (Claude Code); every change reviewed, tested, and owned by the author.

---

CI: red by construction until #118 lands

The test job fails on duplicate key value violates unique constraint "res_country_state_name_code_uniq" (Ladakh / Odisha). That is not this branch:
base's pre-migration, which renames base.state_in_or → base.state_in_od
and l10n_in.state_in_la → base.state_in_la, lives in #118 and is not on
20.0 yet. Every branch cut from 20.0 alone hits it, which is why #117 is red
for the same reason.

Per the fork's model the per-PR test check is the lean one; the real migration
gate is the integration branch (#120), where this module's scripts run green as
part of the full 585-module seed.