[19.0][MIG] hr_recruitment#5612
Open
hbrunn wants to merge 1 commit into
Open
Conversation
Member
Author
|
/ocabot migration hr_recruitment |
Comment on lines
+16
to
+18
| openupgrade.lift_constraints( | ||
| env.cr, openupgrade.get_legacy_name("hr_candidate"), "id", cascade=True | ||
| ) |
Contributor
There was a problem hiding this comment.
Suggested change
| openupgrade.lift_constraints( | |
| env.cr, openupgrade.get_legacy_name("hr_candidate"), "id", cascade=True | |
| ) | |
| openupgrade.remove_tables_fks( | |
| env.cr, [openupgrade.get_legacy_name("hr_candidate")] | |
| ) |
cleaner and safer
Member
Author
There was a problem hiding this comment.
they do different things, I think we need both actually
Contributor
There was a problem hiding this comment.
I thought all the things that lift_constraints does are included in remove_tables_fks. If not, then put both 🤷♂️
This was referenced May 15, 2026
dnplkndll
added a commit
to ledoent/OpenUpgrade
that referenced
this pull request
May 15, 2026
Adds upgrade_analysis_work.txt for the 4 hr_* submodules with
substantial 19.0 deltas: hr_attendance, hr_holidays_attendance,
hr_skills, hr_recruitment_skills.
These cluster into two logical refactors that are already covered by
apriori.renamed_models:
hr.attendance.overtime → hr.attendance.overtime.line
(hr_attendance, hr_holidays_attendance)
hr.candidate.skill → hr.applicant.skill
(hr_recruitment_skills)
For both clusters the apriori rename handles the data move. The
many2many table "now hr_applicant_hr_skill_rel ('False')" matches
Odoo's auto-naming for hr.applicant ↔ hr.skill (alphabetical
hr_applicant_hr_skill_rel) and hr.employee ↔ hr.skill, so no explicit
rename_tables is needed.
NEW models (overtime rule, overtime ruleset, skill history report,
certification report, hr.individual.skill.mixin, hr.job.skill) are
created by the 19.0 module load. NEW fields all carry hasdefault
(default or compute). NEW required+function fields are computed by
Odoo at registry init. DEL fields/views/access are preserved per the
maintainer's philosophy; database_cleanup handles residuals once 19.0
is in active use.
Companion to OCA#5634 ([19.0][MIG] hr_* for 13 simple submodules); same
review precedent as OCA#5633.
hr, hr_expense, hr_holidays, hr_work_entry are already done.
hr_recruitment (OCA#5612) is in flight by @hbrunn.
dnplkndll
added a commit
to ledoent/OpenUpgrade
that referenced
this pull request
May 15, 2026
Adds upgrade_analysis_work.txt for the 4 hr_* submodules with
substantial 19.0 deltas: hr_attendance, hr_holidays_attendance,
hr_skills, hr_recruitment_skills.
These cluster into two logical refactors that are already covered by
apriori.renamed_models:
hr.attendance.overtime → hr.attendance.overtime.line
(hr_attendance, hr_holidays_attendance)
hr.candidate.skill → hr.applicant.skill
(hr_recruitment_skills)
For both clusters the apriori rename handles the data move. The
many2many table "now hr_applicant_hr_skill_rel ('False')" matches
Odoo's auto-naming for hr.applicant ↔ hr.skill (alphabetical
hr_applicant_hr_skill_rel) and hr.employee ↔ hr.skill, so no explicit
rename_tables is needed.
NEW models (overtime rule, overtime ruleset, skill history report,
certification report, hr.individual.skill.mixin, hr.job.skill) are
created by the 19.0 module load. NEW fields all carry hasdefault
(default or compute). NEW required+function fields are computed by
Odoo at registry init. DEL fields/views/access are preserved per the
maintainer's philosophy; database_cleanup handles residuals once 19.0
is in active use.
Companion to OCA#5634 ([19.0][MIG] hr_* for 13 simple submodules); same
review precedent as OCA#5633.
hr, hr_expense, hr_holidays, hr_work_entry are already done.
hr_recruitment (OCA#5612) is in flight by @hbrunn.
dnplkndll
added a commit
to ledoent/OpenUpgrade
that referenced
this pull request
May 15, 2026
Adds upgrade_analysis_work.txt for the 4 hr_* submodules with
substantial 19.0 deltas: hr_attendance, hr_holidays_attendance,
hr_skills, hr_recruitment_skills.
These cluster into two logical refactors that are already covered by
apriori.renamed_models:
hr.attendance.overtime → hr.attendance.overtime.line
(hr_attendance, hr_holidays_attendance)
hr.candidate.skill → hr.applicant.skill
(hr_recruitment_skills)
For both clusters the apriori rename handles the data move. The
many2many table "now hr_applicant_hr_skill_rel ('False')" matches
Odoo's auto-naming for hr.applicant ↔ hr.skill (alphabetical
hr_applicant_hr_skill_rel) and hr.employee ↔ hr.skill, so no explicit
rename_tables is needed.
NEW models (overtime rule, overtime ruleset, skill history report,
certification report, hr.individual.skill.mixin, hr.job.skill) are
created by the 19.0 module load. NEW fields all carry hasdefault
(default or compute). NEW required+function fields are computed by
Odoo at registry init. DEL fields/views/access are preserved per the
maintainer's philosophy; database_cleanup handles residuals once 19.0
is in active use.
Companion to OCA#5634 ([19.0][MIG] hr_* for 13 simple submodules); same
review precedent as OCA#5633.
hr, hr_expense, hr_holidays, hr_work_entry are already done.
hr_recruitment (OCA#5612) is in flight by @hbrunn.
dnplkndll
added a commit
to ledoent/OpenUpgrade
that referenced
this pull request
May 15, 2026
Adds upgrade_analysis_work.txt for the 13 unclaimed hr_* submodules
whose 19.0 deltas are auto-handled by Odoo's standard upgrade flow.
Modules covered:
hr_calendar, hr_fleet, hr_gamification, hr_homeworking, hr_livechat,
hr_maintenance, hr_org_chart, hr_presence, hr_recruitment_sms,
hr_skills_event, hr_skills_slides, hr_skills_survey, hr_timesheet.
All blocks annotate as # NOTHING TO DO — NEW XML records are created
by the 19.0 module load, DEL records are removed by the standard
upgrade flow, "module is now 'X' ('Y')" entries are field-ownership
shifts that the standard upgrade reconciles, and selection_keys /
function-becomes-stored / type changes are auto-handled at registry
init.
Mirrors hbrunn's existing annotation-only [MIG] PRs ([MIG] bus,
[MIG] http_routing, [MIG] resource_mail). The 4 substantial
hr_attendance / hr_skills / hr_recruitment_skills /
hr_holidays_attendance modules are deliberately split into a
companion PR for focused review of the overtime/skills refactor.
hr, hr_expense, hr_holidays, hr_work_entry are already done.
hr_recruitment (OCA#5612) is in flight by hbrunn.
hr_recruitment_survey and hr_work_entry_holidays have no analysis
delta — left for a future regen.
dnplkndll
added a commit
to ledoent/OpenUpgrade
that referenced
this pull request
May 15, 2026
Adds upgrade_analysis_work.txt for the 4 hr_* submodules with
substantial 19.0 deltas: hr_attendance, hr_holidays_attendance,
hr_skills, hr_recruitment_skills.
These cluster into two logical refactors that are already covered by
apriori.renamed_models:
hr.attendance.overtime → hr.attendance.overtime.line
(hr_attendance, hr_holidays_attendance)
hr.candidate.skill → hr.applicant.skill
(hr_recruitment_skills)
For both clusters the apriori rename handles the data move. The
many2many table "now hr_applicant_hr_skill_rel ('False')" matches
Odoo's auto-naming for hr.applicant ↔ hr.skill (alphabetical
hr_applicant_hr_skill_rel) and hr.employee ↔ hr.skill, so no explicit
rename_tables is needed.
NEW models (overtime rule, overtime ruleset, skill history report,
certification report, hr.individual.skill.mixin, hr.job.skill) are
created by the 19.0 module load. NEW fields all carry hasdefault
(default or compute). NEW required+function fields are computed by
Odoo at registry init. DEL fields/views/access are preserved per the
maintainer's philosophy; database_cleanup handles residuals once 19.0
is in active use.
Companion to OCA#5634 ([19.0][MIG] hr_* for 13 simple submodules); same
review precedent as OCA#5633.
hr, hr_expense, hr_holidays, hr_work_entry are already done.
hr_recruitment (OCA#5612) is in flight by @hbrunn.
dnplkndll
added a commit
to ledoent/OpenUpgrade
that referenced
this pull request
May 16, 2026
Adds upgrade_analysis_work.txt for the 4 hr_* submodules with
substantial 19.0 deltas: hr_attendance, hr_holidays_attendance,
hr_skills, hr_recruitment_skills.
These cluster into two logical refactors that are already covered by
apriori.renamed_models:
hr.attendance.overtime → hr.attendance.overtime.line
(hr_attendance, hr_holidays_attendance)
hr.candidate.skill → hr.applicant.skill
(hr_recruitment_skills)
For both clusters the apriori rename handles the data move. The
many2many table "now hr_applicant_hr_skill_rel ('False')" matches
Odoo's auto-naming for hr.applicant ↔ hr.skill (alphabetical
hr_applicant_hr_skill_rel) and hr.employee ↔ hr.skill, so no explicit
rename_tables is needed.
NEW models (overtime rule, overtime ruleset, skill history report,
certification report, hr.individual.skill.mixin, hr.job.skill) are
created by the 19.0 module load. NEW fields all carry hasdefault
(default or compute). NEW required+function fields are computed by
Odoo at registry init. DEL fields/views/access are preserved per the
maintainer's philosophy; database_cleanup handles residuals once 19.0
is in active use.
Companion to OCA#5634 ([19.0][MIG] hr_* for 13 simple submodules); same
review precedent as OCA#5633.
hr, hr_expense, hr_holidays, hr_work_entry are already done.
hr_recruitment (OCA#5612) is in flight by @hbrunn.
dnplkndll
added a commit
to ledoent/OpenUpgrade
that referenced
this pull request
May 16, 2026
Captures coverage map (309 catalog, 187 our fork, 72 truly unclaimed with 71 non-US l10n_* deferred per fork-only rule), seed-tier plan (woodbimble CE-only → OCA-stacked), open PR review list (5 Ledo drafts held + OCA#5612 hbrunn hr_recruitment to review), and CI infra reference. Lives under docs/ — gets force-pushed onto ledoent only. Aggregator won't pull it into upstream since it's not in origin/19.0.
dnplkndll
added a commit
to ledoent/OpenUpgrade
that referenced
this pull request
May 16, 2026
Manual on-demand CI for the woodbimble + volume seed
(18.0-ledoent-mc-large.psql). Triggered via:
gh workflow run test-migration-multicompany-large.yml \
--repo ledoent/OpenUpgrade --ref <branch>
Built by scripts/seed-multicompany-large.py (manual run on the runner)
layered on the structural multi-company seed. Adds:
- 2-level branch nesting (Wood -> US East -> NJ Warehouse)
- per-branch account.move history (incl. cancelled state)
- 3 intercompany draft invoices (Wood<->Bimble, Showroom->Wood)
- service products pinned to Bimble, retail pinned to Showroom
- res.partner.bank rows on two companies for one shared partner
- Showroom POS config (the gap Phase B couldn't auto-fill)
Use cases:
- pre-submit on own migrations touching account / stock_account /
purchase / sale / intercompany / branch-traversal code
- review of OCA PRs where multi-company depth matters (e.g.
hbrunn OCA#5612 branch-traversal concern in hr_recruitment)
dnplkndll
added a commit
to ledoent/OpenUpgrade
that referenced
this pull request
May 16, 2026
Multi-company seed (18.0-ledoent-mc.psql) live on fork release; test-migration-multicompany.yml workflow firing on push. Large seed script + workflow_dispatch-only workflow drafted but not yet run on runner. Open OCA PR list now shows only hbrunn OCA#5612 with our 2026-05-16 review notes (cascade=True was-bug-now-resolved; multi- company branch traversal flag still valid).
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
3 participants
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.
depends on: