Four customer-feedback fixes (G1-G4):
G1 — Part cell display redundancy. fp.part.catalog.display_name was
showing 'PART (Rev X) — Name' which duplicated with my Part cell widget's
separately-rendered revision + name rows. Added @api.depends_context
('fp_express_part_picker') to _compute_display_name: when the context
flag is True, display_name returns JUST the part_number. The Express
view passes the flag on the part_catalog_id field, so the picker shows
'9876699373' and the widget's row 2/3 show the rev + name.
G2 — Material/Process Tag is now the order's RECIPE, not a free-text
shop tag. Converted material_process from Char to Many2One(fusion.
plating.process.node) with domain [('node_type','=','recipe')] on both
fp.direct.order.wizard AND sale.order. Pre-migration (19.0.22.1.0/
pre-migrate.py) drops the old VARCHAR column so Odoo recreates as
INTEGER FK. Per dev-stage policy, old tag data is dropped.
G3 — Auto-apply order recipe to every line. New onchange
_onchange_material_process_apply_to_lines on the wizard: when the
header recipe is picked / changed, propagate to every line's
process_variant_id (unless the line has an explicit per-line override
that doesn't match the previous header value).
Plus an override on fp.direct.order.line.create that seeds new lines'
process_variant_id from wizard.material_process. So a newly-added
line auto-inherits the order's recipe.
G4 — Auto-sync line edits back to the part catalog. New
_fp_sync_to_part method called from create() + write() on
fp.direct.order.line. Tracked fields:
- line_description → part.default_specification_text
- bake_instructions → part.default_bake_instructions
- thickness_range → part.x_fc_default_thickness_range
- masking_enabled → part.default_masking_enabled
- process_variant_id → part.default_process_variant_id
Future orders for the same part will auto-pull these updated defaults
via the existing _onchange_part_default_thickness chain. Last-write-
wins semantics across concurrent edits (acceptable per dev-stage).
38 lines
1.4 KiB
Python
38 lines
1.4 KiB
Python
# -*- coding: utf-8 -*-
|
|
"""Pre-migration for 19.0.22.1.0 — material_process Char → Many2One.
|
|
|
|
The material_process field on fp.direct.order.wizard was originally a
|
|
free-text Char tag for shop-level metadata (e.g. "ENP-STEEL-HP-ADVANCED").
|
|
Per 2026-05-27 customer feedback, it should instead link directly to a
|
|
recipe (fusion.plating.process.node, node_type='recipe') so that picking
|
|
a tag auto-applies the recipe to every order line.
|
|
|
|
Drop the old VARCHAR column so Odoo can recreate it as an INTEGER FK
|
|
when the new field declaration loads. Per the Express Orders spec
|
|
section 12 (dev-stage, ignore past orders), losing the old Char values
|
|
is acceptable.
|
|
|
|
Idempotent — IF EXISTS guards mean a re-run is safe.
|
|
"""
|
|
|
|
|
|
def migrate(cr, version):
|
|
# Same model needs the same pre-migration on sale.order too
|
|
for table, column in (
|
|
('fp_direct_order_wizard', 'material_process'),
|
|
('sale_order', 'x_fc_material_process'),
|
|
):
|
|
cr.execute("""
|
|
SELECT data_type FROM information_schema.columns
|
|
WHERE table_name = %s AND column_name = %s
|
|
""", (table, column))
|
|
row = cr.fetchone()
|
|
if not row:
|
|
continue
|
|
data_type = row[0]
|
|
# Only drop if the existing column is the old Char shape
|
|
if data_type in ('character varying', 'text'):
|
|
cr.execute(
|
|
f"ALTER TABLE {table} DROP COLUMN IF EXISTS {column}"
|
|
)
|