[19.0][MIG] hr_expense_payment: Migration to 19.0 - #355
Conversation
bc36318 to
e3d066b
Compare
78afa4d to
5f7aadb
Compare
8fa0294 to
17e1706
Compare
|
Please squash the commits as explained here: https://github.com/OCA/maintainer-tools/wiki/Merge-commits-in-pull-requests#mergesquash-the-commits-generated-by-bots-or-weblate |
(cherry picked from commit 958f048)
(cherry picked from commit 1fb90c1)
(cherry picked from commit 288a719)
(cherry picked from commit caf1f0b)
(cherry picked from commit e242daf)
Currently translated at 100.0% (6 of 6 strings) Translation: hr-expense-16.0/hr-expense-16.0-hr_expense_payment Translate-URL: https://translation.odoo-community.org/projects/hr-expense-16-0/hr-expense-16-0-hr_expense_payment/it/ (cherry picked from commit 4aee4df)
(cherry picked from commit c797712)
(cherry picked from commit c71a6fa)
(cherry picked from commit 69560c7)
Related to odoo/odoo@2dc6b6c (cherry picked from commit 8692a69)
(cherry picked from commit 6660847)
…thod (cherry picked from commit a82dace)
Currently translated at 100.0% (5 of 5 strings) Translation: hr-expense-18.0/hr-expense-18.0-hr_expense_payment Translate-URL: https://translation.odoo-community.org/projects/hr-expense-18-0/hr-expense-18-0-hr_expense_payment/it/ (cherry picked from commit 0b64eb0)
17e1706 to
093ce9c
Compare
pilarvargas-tecnativa
left a comment
There was a problem hiding this comment.
@Tecnativa TT58634
Have you checked whether this functionality has already been incorporated into Odoo 19 core?
@victoralmau @carlos-lopez-tecnativa please, take a look
| expense_sheet_ids = fields.Many2many( | ||
| comodel_name="hr.expense.sheet", | ||
| relation="payment_expense_sheet_rel", | ||
| expense_ids = fields.Many2many( |
There was a problem hiding this comment.
You are redefining this existing field in the model
https://github.com/odoo/odoo/blob/c47af9c0596a39a7a5d0d7b6709d2d796ab3d56e/addons/hr_expense/models/account_payment.py#L10
With these changes, the standard field is replaced by an independent Many2many using a new relation table. This duplicates the standard relationship and could leave both relations out of sync.
There is also no migration script for the existing data in payment_expense_sheet_rel.
A post_init_hook will only run when installing the module, not when upgrading an existing database, and the current implementation may also miss partially reconciled payments.
Address review on OCA#355 (pilarvargas-tecnativa): - Do not redefine account.payment.expense_ids: 19.0 core already owns that field (related to move_id.expense_ids, i.e. company-paid expenses) and hangs logic off it (_compute_outstanding_account_id, the write() guard, action_open_expense). The module field is renamed to reconciled_expense_ids. - Replace the stored Many2many + wizard context threading + post_init hook with fields computed from the reconciliation, using core's account.move._get_reconciled_payments()/_get_reconciled_amls() helpers (the reconciled_bill_ids pattern). The link can never go out of sync with the standard relationship, includes partially reconciled payments, and works however the payment was registered. - compute_sudo on both fields: employees can read their expenses without accounting access, so the reconciliation walk needs sudo. - No migration script needed anymore: nothing is stored, so 18.0 payment_expense_sheet_rel data is superseded by the reconciliation itself on upgraded databases. - Tests cover: core field not overridden, back-link on register payment, partial payment, grouped multi-expense payment, unreconcile dissolving the link, searchability of both computed fields, employee (non-accounting) read access, and company-paid expenses staying core-only.
093ce9c to
3fa1c43
Compare
| compute_sudo=True, | ||
| search="_search_reconciled_expense_ids", | ||
| help="Employee-paid expenses whose journal items have been reconciled " | ||
| "with this payment.", |
There was a problem hiding this comment.
Thanks for the changes. However, please make sure that the functionality provided by this module has not already been incorporated into Odoo 19 core.
Also, the existing relationships stored in payment_expense_sheet_rel are not migrated. Since the new computed field is not stored, it only derives relationships from the available accounting data. Could you confirm that this reliably preserves all existing links, including historical ones?
The OpenUpgrade migration scripts for hr_expense may be useful as a reference for reviewing how the standard expense-payment relationships and their existing data are handled.
41cb11b to
195d4a9
Compare
- Nothing stored anymore: payment_ids = account_move_id. reconciled_payment_ids; reconciled_expense_ids = (invoice_ids | reconciled_bill_ids).expense_ids. Core's expense_ids covers company-paid only. Wizard override and post_init_hook dropped. - migrations/19.0.1.0.0: carry rel rows whose reconciliation was undone into account_move__account_payment via former_sheet_id; idempotent, no-op when absent/unfilled. Assisted-by: Claude Opus 5
195d4a9 to
79f5505
Compare
|
@pilarvargas-tecnativa |
OCA no mantiene estos 8 módulos que DJI usa en 19.0 (no existe rama 19.0 en sus repos), pero cada uno tiene un Pull Request abierto (sin fusionar) que sí los migra. Decisión del usuario: usar esos PRs en vez de forkear desde cero. Renombrados con prefijo xtendoo_ para evitar colisión de nombre técnico si OCA fusiona el PR original más adelante. - xtendoo_web_company_color <- OCA/web#3326 (HeliconiaIO/web) - xtendoo_hr_expense_cancel <- OCA/hr-expense#356 (ledoent/hr-expense) - xtendoo_hr_expense_payment <- OCA/hr-expense#355 (ledoent/hr-expense) - xtendoo_website_whatsapp <- OCA/website#1207 (Jarsa-dev/website) - xtendoo_stock_picking_mass_action <- OCA/stock-logistics-workflow#2161 (adhoc-dev/stock-logistics-workflow) - xtendoo_sale_report_margin <- OCA/margin-analysis#281 (ursais/margin-analysis) - xtendoo_product_pricelist_direct_print <- OCA/product-attribute#2220 (Studio73/product-attribute) - xtendoo_account_move_line_stock_info <- OCA/stock-logistics-warehouse#2549 (collinskipkorir/stock-logistics-warehouse) - version bump 18.0->19.0 aplicado a mano, el PR original no lo traía Además de renombrar directorio/manifest, corregidas referencias técnicas reales que dependían del nombre del módulo (no solo cosméticas): report_name/t-call/env.ref en product_pricelist_direct_print, ir.model. access.csv + view id en stock_picking_mass_action, ruta de assets estáticos en website_whatsapp (URL /website_whatsapp/static/... hubiera dado 404), e imports de tests/__init__.py tras renombrar los ficheros de test. 3 módulos descontinuados (website_sale_product_description, stock_picking_warn_message, account_payment_order_return) NO se implantan en 19.0, decisión explícita del usuario.
Port of
hr_expense_paymentfrom 18.0 to 19.0 (migration guide).Non-mechanical adaptations worth flagging
hr.expense.payment_idsdelegates to coreaccount_move_id.reconciled_payment_ids;account.payment.reconciled_expense_ids = (invoice_ids | reconciled_bill_ids).expense_ids(core'sexpense_idscovers company-paid only). Register-wizard override andpost_init_hookdropped; both fieldscompute_sudo+ searchable.migrations/19.0.1.0.0/post-migration.pycarries 18.0payment_expense_sheet_relrows whose reconciliation was since undone into core'saccount_move__account_paymentviaformer_sheet_id; idempotent, no-op on fresh installs or when the pointer is unfilled.AI-assisted (Claude Code); every change reviewed, tested, and owned by the author.