[les-adhoc]

Tarea: https://www.adhoc.inc/odoo/project.task/76375

Migration of purchase_ux from 19.0 to 20.0. The behaviour stays the same as in 19.0.

Changes

• Migrator: version 20.0.1.0.0 and installable.
• upgrade_code 19.4-00-ir-access: ir.model.access.csv becomes ir.access.csv. Same groups and operations as in 19.0.
• Icons: fa-bullseye becomes crisis_alert.
• 20.0 API:
  • purchase.order.line and product.supplierinfo: product_uom_id is now uom_id.
  • _get_date_planned takes the seller info dict, so the code uses _get_seller_info().
  • purchase.bill.line.match: _table_query is now _table_sql.
  • The matching list view shows description instead of display_name. The module still replaces it with reference_description.
  • The module search view on matching extends the one that purchase adds in 20.0, so the native filters and groupings stay.
  • get_param is now get_str.
• models/ir_model_access.py is removed: it was never imported.
• Tests: ProductCommon runs as a product manager since 20.0, so TestPurchaseOrder keeps running as admin, as purchase does in its own tests. New tests cover the wizard access in ir.access.csv, the read-only form of the Purchase Lines menu and the units of measure guard.
• reference_description drops its Description label, which clashed with the native description field. The views still show "Description".
• Brings the 19.0 commits f5d78e1 (dashboard card, from [IMP] purchase_ux: clarify the "Not Acknowledged" purchase dashboard card #382), e1ac051 and ca324c4 (res_partner.xlsx, from [FIX] base_ux: remove 'Capital Federal' from contact import template #392) and adapts the card to the 20.0 template. The 19.0 fix 28154ba ([FIX] purchase_ux: use product_uom_id when initializing date_planned on confirmed lines #379) is covered by the switch to _get_seller_info().
• [FIX]: the decimal precision is called Product Unit since 19.0. The module used Product Unit of Measure, which silently fell back to 2 digits and could round the quantity to bill.
• [REM]: drop the "Lines per page" setting. Odoo removed the limit="200" of the order line list ([FIX] purchase: remove order line limit odoo/odoo#291285), so 20.0 is back to the default of 40 lines per page, which is what the setting was added for. Measured on a 300-line order: 40 rows open in about half the time of 200 rows.
• README synced with the module, translations exported and completed.

Also in the [MIG] commit, after the review:

• The new native form purchase_order_line_view_form_invoice became the default one in 20.0. The Purchase Lines menu and action_line_form open purchase_order_line_form2 again, and the new form gets the same read-only restriction.
• The bill matching search view now extends the native one, and the module _order is dropped in favour of the native one, which keeps matched pairs together.
• Tests for the access that ir.access.csv grants to both wizards.
• The guard for incompatible units of measure also covers the native "Qty to invoice" column, so those lines show nothing to invoice, as in 19.0.
• A test checks that the Purchase Lines menu opens the read-only purchase_order_line_form2.

depends and auto_install are unchanged. The manifest adds assets for the dashboard card. The purchase_ux.order_line_view_limit system parameter stays in upgraded databases, unused. The license stays AGPL-3: no dependency reaches Enterprise.

No data migration script is needed. The fields that change are core fields and the Odoo upgrade migrates them. The module stored fields keep their shape and meaning.

Test plan

• Install on a fresh 20.0 database with demo data. It installs with no warnings and the 19 module tests pass.
• Order with a product that has no vendor price: the line takes the product cost.
• Change currency, update prices and update vendor prices from the order.
• Force the invoice status (debug mode): it stays after editing the order.
• Purchase settings: "Skip Bill File Upload" is still there and "Lines per page" is gone. Long orders show 40 lines per page.
• Draft vendor bill: the purchase matching button opens the pending lines of the vendor and its contacts, with the module columns and filters.
• Purchase dashboard: the "Not Acknowledged nor Received" card.

Runbot does not run the 19.0 → 20.0 upgrade yet, so this was not tested on an upgraded database.

[roboadhoc]

[mav-adhoc]

@roboadhoc r+ nobump rebase-ff

[roboadhoc]

Merge method set to rebase and fast-forward.

[mav-adhoc]

@roboadhoc check

[roboadhoc]

Updated message. No update to pr head.

[mav-adhoc]

Revisión adversarial de la migración (solo lectura, no bloquea el merge). El detalle completo, con la evidencia de cada punto, está en la nota interna de la tarea 76375: https://www.adhoc.inc/odoo/project.task/76375

Alta · del salto

• purchase_order_line_form2 deja de ser el formulario por defecto de purchase.order.line en 20: core suma purchase_order_line_view_form_invoice (primaria, prioridad por defecto 16, addons/purchase/views/purchase_views.xml:863) y form2 tiene priority=20 (:820); default_view toma la de menor prioridad (odoo/addons/base/models/ir_ui_view.py:149, :699-712). El edit="false" delete="false" que el módulo le hereda a form2 queda inerte en el menú propio Purchase Lines y en action_line_form. No verificado en runtime.

Media · del salto

• El priority 15 que suma el PR a la search view de purchase.bill.line.match tapa la search view nueva de core 20 (purchase_bill_line_match_views.xml:33): se pierden Matched/Unmatched y el agrupar por Matching.
• _order del módulo sigue siendo el de 19 y descarta el de core 20 (matching_id desc, aml_id desc, product_id).
• Core 20 sacó el filtro de pendientes de _select_po_line y lo movió al dominio de action_purchase_matching; desde el botón Bill Matching de la orden (sin override) ahora aparecen líneas ya facturadas.
• Ningún test ejercita el ir.access.csv nuevo: los 4 de test_purchase_order.py optan por _test_user_groups = None y los otros 8 lo heredan en None de AccountTestInvoicingCommon.
• La baja del ajuste "Líneas por página" no la fuerza el salto (el ancla purchase_setting_container sigue en 20): es decisión de producto, informada al PO y sin respuesta.

Bajas

• Pendiente de 19.0: ca324c4 (static/xls/res_partner.xlsx, 21/10), con FW abierto [FIX] base_ux: remove 'Capital Federal' from contact import template #392.
• //field[@name='product_uom_qty'] matchea dos nodos en core 20 y Odoo toma el primero: "Qty Received" queda entre "Bill Qty" y "Qty to invoice".
• reference_description pierde su string="Description".

Dos puntos del reporte, corregidos

• Los @api.depends de un override se unen a los de core, no los pisan (odoo/orm/fields.py:599-636, :51). El síntoma de _get_invoiced sigue en pie: falta order_line.invoice_status, y es preexistente.
• uom.uom._compute_quantity no levanta excepción, ni en 19 ni en 20 (addons/uom/models/uom_uom.py:139-169): la columna nueva muestra un número sin sentido, no rompe la lista.

Verificado y bien: ir_model_access.py ya era código muerto en 19.0; _get_seller_info() sí cubre 28154ba; el <a> del dashboard coincide con core 20; ir.access.csv correcto; anclas, xmlids de data y demo, licencia, static_check y check_metodos limpios. No reproduje la instalación ni los tests: falta account_ux de 20 en mi checkout.

[mav-adhoc]

Tercera ronda sobre e87d1aa. Los seis arreglos están verificados contra core 20 y correctos; CI en verde sobre ese head. Nada bloqueante. Tres cosas:

1. Media · del salto — la guarda de unidades no aplica por el botón Bill Matching de la orden. El flag purchase_matching_from_button lo setea solo models/account_move.py:93; purchase.order.action_bill_matching es de core (purchase_order.py:764) y no lo pisás. Y en 20 ese camino muestra justo la columna guardada: "PO Qty" quedó optional="hide" y la visible por defecto es product_uom_qty_to_invoice (purchase_bill_line_match_views.xml:21-23). El test nuevo entra por la factura, no por ahí. ¿Entra en el alcance o se deja?
2. Media — el edit="false" de purchase_order_line_view_form_invoice quedó sin test (purchase_line_views.xml:52-62); el test nuevo solo afirma sobre form2. Es la vista que abre cualquier otro camino, por ser el default de 20.
3. Media — a zem le falta un dato. En 20 el botón nativo se ve siempre (addons/purchase/views/account_move_views.xml:49); en 19 se escondía con is_purchase_matched y el módulo lo limita a draft/cancel. Si elige el nativo, también cambia cuándo aparece: en facturas publicadas y ya conciliadas.

Bajas: los dos campos guardados por contexto no declaran depends_context; las seis condiciones con done quedan inertes (preexistentes, igual que en 19.0); "Líneas por página" sigue sin respuesta de zem; y el video no cubre los dos pasos que cambiaron los commits de revisión.

Fuera de mi alcance: no instalé ni corrí los tests; los 18 en verde los respalda el runbot del head, no yo.

[mav-adhoc]

Cuarta pasada, sobre dc5c455. Del código, nada nuevo: el árbol de purchase_ux es byte por byte idéntico a c25d8b3, que ya verifiqué y di por correcto. 19 tests; ci/runbot-oba del head todavía PENDING.

Un punto, y es de proceso: el force-push (c25d8b3...dc5c455) aplastó los tres commits de revisión — "address the migration review", "second round" y "third round" ya no están en el log, su contenido quedó dentro de los commits originales. La convención dice que desde que una persona revisó no se reescribe la historia: cada ronda va en un commit nuevo al final y se mergea así. Lo reviso igual porque el contenido está intacto, pero los commits que revisé no son los que se van a mergear, y el r+ se cae con cada force-push.

De mi lado no queda nada abierto. Falta el runbot y la respuesta de zem sobre el botón.

[ced-adhoc]

@roboadhoc r+