Skip to content

[20.0][IMP] openupgrade_scripts: fill full apriori #6077

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
MiquelRForgeFlow wants to merge 1 commit into
base: 20.0
Choose a base branch
from
Open

[20.0][IMP] openupgrade_scripts: fill full apriori #6077

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 57 additions & 1 deletion openupgrade_scripts/apriori.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,8 @@
# Renamed modules is a mapping from old module name to new module name
renamed_modules = {
# odoo
"purchase_requisition_sale": "purchase_alternative_sale",
"website_sale_autocomplete": "website_address_autocomplete",
# odoo/enterprise
# OCA/...
}
Expand All @@ -13,20 +15,74 @@
# preexisting module names
merged_modules = {
# odoo
"account_add_gln": "account",
"account_peppol_response": "account_peppol",
"base_iban": "account",
"base_vat": "base",

@FerDeNetlab FerDeNetlab Nov 3, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

base_vat was split: the format checks went to base, but VIES (vies_valid, vat_check_vies, the cron) went to the new l10n_eu_account_vies. Merging into base drops VIES on databases that use it; renaming it (what we did locally) installs VIES on every database that had base_vat, also outside the EU. Maybe merge into base and install l10n_eu_account_vies in a script when a company has vat_check_vies? What would you prefer?

@MiquelRForgeFlow MiquelRForgeFlow Nov 4, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe merge into base and install l10n_eu_account_vies in a script when a company has vat_check_vies?

Exactly.

"delivery_stock_picking_batch": "stock_delivery",
"hr_holidays_homeworking": "hr_holidays",
"hr_homeworking": "hr",
"hr_homeworking_calendar": "hr_calendar",
"hr_hourly_cost": "hr",
"hr_org_chart": "hr",
"hr_work_entry_holidays": "hr_holidays",
"l10n_cn_city": "l10n_cn",
"l10n_dk_nemhandel": "l10n_dk",
"l10n_dk_nemhandel_response": "l10n_dk",
Comment thread
MiquelRForgeFlow marked this conversation as resolved.
Resolved
"l10n_dk_oioubl": "l10n_dk",
"l10n_ec_stock": "l10n_ec",
"l10n_fr_hr_work_entry_holidays": "l10n_fr_hr_holidays",
"l10n_hu_edi_receive": "l10n_hu_edi",
"l10n_latam_base": "account",
"l10n_lk_invoice": "l10n_lk",
"l10n_pl_bank_verification": "l10n_pl",
"l10n_ro_cpv_code": "l10n_ro_edi",
"l10n_ro_edi_stock_batch": "l10n_ro_edi_stock",
"l10n_sa_withholding_tax": "l10n_sa",
"l10n_tr_gib_invoice_scenarios": "l10n_tr_nilvera_einvoice",
"l10n_tr_nilvera_base_vat": "l10n_tr_nilvera",
"l10n_tr_nilvera_einvoice_extended": "l10n_tr_nilvera_einvoice",
"l10n_uy_pos": "l10n_uy",
"pos_restaurant_adyen": "pos_adyen",
"pos_restaurant_stripe": "pos_stripe",
"pos_self_order_adyen": "pos_adyen",
"pos_self_order_stripe": "pos_stripe",
Comment thread
MiquelRForgeFlow marked this conversation as resolved.
Resolved
"pos_self_order_viva_com": "pos_viva_com",
"stock_picking_batch": "stock",
"website_sale_collect_wishlist": "website_sale_collect",
"website_sale_comparison": "website_sale",
"website_sale_comparison_wishlist": "website_sale",
"website_sale_stock_wishlist": "website_sale_stock",
"website_sale_wishlist": "website_sale",
# odoo/enterprise
# OCA/...
"iot_base": "iot",
Comment thread
MiquelRForgeFlow marked this conversation as resolved.
Resolved
# OCA/stock-logistics-warehouse
"stock_move_quantity_product_uom": "stock",
}

# only used here for upgrade_analysis
renamed_models = {
# odoo
"calendar.popover.delete.wizard": "calendar.event.archive.or.unlink.wizard",
"google.calendar.sync": "google.event.sync",
"hr.contract.type": "hr.employee.type",
"l10n_hu_edi_receive.bills.wizard": "l10n_hu_edi.receive.bills.wizard",
"l10n_tr_nilvera_einvoice_extended.tax.office": "l10n_tr.tax.office",
"purchase.requisition.alternative.warning": "purchase.alternative.warning",
"purchase.requisition.create.alternative": "purchase.alternative.create",
"stock_account.stock.valuation.report": "account.stock.valuation.report",
"website.base.unit": "product.base.unit",
# OCA/...
}

# only used here for upgrade_analysis
merged_models = {
# odoo
"crm.lead2opportunity.partner": "crm.lead2opportunity.partner.mass",
"hr.leave.type": "hr.work.entry.type",
"ir.model.access": "ir.access",
"ir.rule": "ir.access",

@hbrunn hbrunn Nov 3, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, I think this will cause messy analysis files. Without this, we get all ir.rule records in one block where we can write NOTHING TO DO and are done with it. With this merge, we get them spread out between all the other ir.access records, and have to deal with them line by line.

that's different from ir.model.access, where v20 usually reuses the xmlid for the ir.access entry.

@MiquelRForgeFlow MiquelRForgeFlow Nov 3, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A priori, I disagree. Why do you have to handle them line by line? What do you mean? I think we only should care if they have changed from noupdate = 1 to 0, and vice versa, which the analysis already provides. And also, if the xmlid name changes, which then the analysis already provides. We should not care in that part if the "ir.access" xmlid name comes from "ir.model.access" or "ir.rule", right? The migration scripts to handle the migration of "ir.model.access" and "ir.rule" don't care about the explicit listed xmlids in the analysis file.

With this merge, we get them spread out between all the other ir.access record

Have you tested how it looks merged? Maybe with an example to compare, a visual thing, we could check which option is better.

"res.bank": "res.partner.bank",
"stock.scrap": "stock.move",
# OCA/...
}
Loading