Repository navigation
Migration to version 20.0 #6044
Description
I'm busy with the prerequisites for the v20 migration:
- base - By @hbrunn - [20.0][MIG] base #6068
- upgrade_analysis: [20.0][MIG] upgrade_analysis server-tools#3748
- openupgrade_scripts: [20.0] initialize branch #6045
- openupgrade_framework: [20.0][MIG] openupgrade_framework #6046
- update testdb cronjob to generate v19 testdb: [19.0][UPD] generate v19 testdb for v20 migration #6043
- update analysis cronjob to generate v19-v20 analysis (in progress, depends on [20.0][MIG] upgrade_analysis server-tools#3748)
Activity
FerDeNetlab commentedon Oct 26, 2026
We've been testing 19.0 → 20.0 on top of #6045, #6046 and the analysis in
20.0-initialize+analysis, with a v19 demo database (crm, sale_management, purchase, stock, account + l10n_mx, project, hr, mrp, point_of_sale; 119 modules). With the scripts below-u allcompletes (131 modules), all 1692 views validate, and accounting moves/lines, quants, sale orders and UoMs are identical to v19.Branch: https://github.com/FerDeNetlab/OpenUpgrade/tree/20.0-netlab-scripts — one commit per module, happy to open one PR per module once #6045 is merged:
apriori: 33 merged modules (hr_org_chart, stock_picking_batch, base_iban, the wishlist/comparison modules, …), 3 renamed modules,hr.contract.type→hr.employee.typeand a few more modelsmail: precreatemail.activity.phone/role_id(the compute crashes onaccount.moveactivities while loading mail), xmlid for the admin's existing #admin membershipaccount: xmlids moved from stock_account,deductible_amount→deductible_percentageproduct,stock,purchase,mrp:product_uom(_id)→uom_id(without it the new field is computed from the product, silently losing the move's UoM),location_final_id→forecasted_location_id,tracking='none'→ NULLsale/sale_management:sale_delayto company dependent jsonb,expense_policy→reinvoice_policy,require_payment→prepayment_percenthr: contract types → employee types,fixed_termpoint_of_sale:use_payment_terminal→payment_provider, storedtype,pos_session_sales_id, …crm_iap_mine,mass_mailing,resource(lunch attendances only),spreadsheet_dashboard,calendar,l10n_mx(bank ABM code →clearing_number)For
basewe only have pieces you may want to reuse:state_in_or→state_in_od(same code, breaks the unique constraint),ir_model_fields.indexboolean → selection (a plain cast yields'true', which breaks manual fields such as analytic plan columns), andres.bank→res.partner.bank. Forir.accesswe only parked the old xmlids; I suppose you're on that.Framework fixes are in a PR against your #6046 branch.
Two things on the analysis (OCA/server-tools#3748):
compare.pynever putsispropertyinreport_fields, so fields that become company dependent without changing type aren't reported (sale_delay,l10n_eg_eta_code); andaccountchanged to 1.6 after the analysis was generated (alsol10n_sk1.1).Bigger pieces still open that we noticed:
account.group→ archived parent accounts (as inupgrade_code/19.3-00-account-groups.py),payment.method.provider_id(one method per provider now),resource.calendar(two weeks calendars,tz,schedule_type),stock.scrap→stock.move.is_scrap.Per the OCA AI policy: this comment and the commits on the linked branch were drafted with AI assistance (Claude Opus 5.5), reviewed by me. The commits now carry an
Assisted-bytrailer.hbrunn commentedon Oct 27, 2026
@FerDeNetlab please review the relevant PRs with line comments where you propose changes, that's where a discussion can be had. Just dumping a bunch of unrelated findings isn't actionable.
kevin3274 commentedon Oct 27, 2026
@hbrunn would you mind pushing your
basework in progress, even if it's incomplete? We are writing module scripts for 20.0 and would like to test them end-to-end on the 19.0 test database.Until then we use a local stopgap that is not meant for a PR: FerDeNetlab's apriori and base commits plus one more xmlid rename. On the OCA 19.0 test database, only two existing states collide with the new
res.country.state.csv:base.state_in_or→base.state_in_odl10n_in.state_in_la→base.state_in_laWith those two renames,
baseanduommigrate without errors.If it helps, we can take a self-contained part of
base, for exampleres.country.stateorres.bank→res.partner.bank. We would send it in whatever form you prefer: suggestions on your PR, or a PR against your branch.Drafted with AI assistance (Claude), reviewed by me.
hbrunn commentedon Oct 27, 2026
I repeat: reviewing the existing PRs to get them merged is much more valuable than any code input at this stage. Especially OCA/server-tools#3748, #6045, #6046 because without them, we can't have automated updates of the analysis files
kevin3274 commentedon Oct 29, 2026
@FerDeNetlab are you still working on hr? We need it for our upgrade path and would like to open the PR, building on your commit c65ce68 (keeping your authorship) and adding what is still missing, e.g. hr.job.user_id → recruiter_id and filling hr.version.tz. Happy to leave it to you if you are about to open it yourself.
FerDeNetlab commentedon Oct 29, 2026
@kevin3274 go ahead, thanks! Besides those two, our commit doesn't map the legacy
employee_typevaluesworker,contractorandfreelance(only employee/student/trainee). Note thatrecruiter_idis anhr.employeenow, so it needs mapping users to their employees rather than a rename. Happy to review the PR.Drafted with AI assistance (Claude Opus 5.5), reviewed by me.