The QR <img> src used `% quote(_scan_url)` to URL-encode the value,
but `quote` isn't always in the QWeb render context — particularly
on the fusion_pdf_preview / account render chains. Result:
KeyError: 'quote' when printing from the browser.
_scan_url is always base_url + '/fp/wo/<int>' — no characters that
need encoding. Replaced the % + quote() formatting with simple
string concatenation, dropping the quote dependency entirely.
Smoke verified on entech: MO + WO stickers render cleanly at 27KB
each (with QR image included).
fusion_plating_reports → 19.0.7.2.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
User reported two issues with the sticker:
1. "Print → WO Box Sticker" didn't appear on the MO form
(WH/MO/00067). The operator workflow lives on the MO form, not
the WO — binding only to mrp.workorder meant they couldn't see
the option. Now bound to BOTH:
* mrp.workorder (per-WO sticker)
* mrp.production (per-MO sticker — prints the MO friendly
name after "WO #" so it reads naturally in shop-floor
vocabulary)
Internal refactor: factored the layout into a shared inner
template report_fp_wo_sticker_inner; the two outer templates
normalise their input to the same _order_id / _scan_id / _mo
variables and t-call the inner.
2. Design polish. The previous layout was a plain label/value
table that looked rough. Redesigned with:
* Proper sticker chrome: 0.5mm black border, 1.5mm rounded
corners, edge padding.
* Header row with bottom border rule separating logo+WO-# on
the left from QR+caption on the right.
* Grid rows now alternate white / #f4f5f7 zebra-striping with
a right-aligned vertical rule between label and value.
* ALL-CAPS, letter-spaced, gray-333 labels at 7.5pt; values
at 8.5pt with strong (9.5pt, 700) emphasis on the key data
(PO, Part Number, Qty) so it reads at a glance from across
the warehouse.
* Helvetica Neue font stack.
* "SCAN TO OPEN" caption under the QR.
Scan endpoint updated: /fp/wo/<id> now tries mrp.production first
(operator home form) then falls back to mrp.workorder. Numeric
collisions between the two id spaces are possible; MO wins because
the MO view carries the full context.
fusion_plating_reports → 19.0.7.1.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Client is migrating from Steelhead and needs to keep the small
parts-box sticker format the warehouse crew already knows. Two
pieces shipped together so scanning is seamless from day one:
1. report_fp_wo_sticker — 4x3" QWeb label bound to mrp.workorder.
Layout mirrors the Steelhead sticker:
* ENTECH logo top-left (via env.company.logo)
* QR code top-right encoding /fp/wo/<id>
* Grid: PO (RO) / Customer / Process / Part Number / Due
Date / Qty / Notes
Dedicated paperformat_fp_wo_sticker at 102x76mm, 300 DPI,
landscape, 3mm margins — sized for thermal / inkjet label
printers without shrink-to-fit.
Binding added so "Print → WO Box Sticker" appears on every
mrp.workorder record.
2. FpWoScanController — GET /fp/wo/<int:wo_id> redirects the
scanner straight to the work-order form
(/odoo/action-mrp.action_mrp_workorder/<id>). auth='user' so
logged-in scanners land on the WO immediately; others bounce
through Odoo's login and return to the same URL. No custom
client work needed — any phone camera, handheld barcode
scanner, or tablet browser opens the URL on scan.
Process row resolution chain: part.default_process_id →
coating.recipe_id → fallback. So the sticker prints whichever
process is actually going to drive WO generation for this line,
matching the direct-order wizard's Effective Process column.
fusion_plating_reports → 19.0.7.0.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
User request: on customer-facing PDFs the single "Part" column was
stacking part number + revision + description together. Split into
two distinct columns so customers see Part Number in its own field
and the Description column carries only the prose.
Macro split:
* customer_line_part_number — strong part number + "(Rev X)"
* customer_line_description — line.name + any populated line
metadata (serial, job#, thickness)
* customer_line_header (legacy) kept as a thin wrapper that
t-calls both macros stacked so older reports still render.
Reports updated — each gains a new first "PART NUMBER" column and
the old "PART" column renamed to "DESCRIPTION":
* report_fp_sale (both portrait variants)
* report_fp_invoice (both portrait variants)
* report_fp_packing_slip (both variants — delivery + MO-origin)
Column widths rebalanced per report. Section / note colspans bumped
to account for the extra column.
report_fp_bol left as-is — its "Description of Goods" td is a
freight-convention combined field, intentionally keeps the stacked
layout via the legacy customer_line_header macro.
fusion_plating_reports → 19.0.6.0.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Customer feedback: some customers don't send their PO with the
initial order — they send it days or weeks later. The system was
blocking SO confirmation without a PO, which forced the shop to
either wait on paperwork or ask a manager for a formal override.
New estimator-level path: a "PO Pending" boolean on sale.order +
an optional "PO Expected By" date.
* Confirm without a PO# / PO document when PO Pending is ticked.
* action_confirm skips the hard error if po_pending OR po_override
is set (keeps the existing manager-override path too).
* On confirm with PO Pending, the system schedules a chase
activity for po_expected_date (or +3 days if blank), assigned
via mail.activity so it shows up in the sales user's activity
list. Chatter note logged so audit is obvious.
* Direct-order wizard: po_number and po_attachment_file become
optional. Ticking "PO Pending" in the wizard is the trade-in;
a help note under the toggle explains the chase behaviour.
* Once the PO arrives, user fills in the PO# / uploads the doc,
and turns PO Pending off — existing downstream flow resumes.
Difference from x_fc_po_override (kept):
* PO Override = manager waiver, permanent ("handshake deal").
* PO Pending = estimator flag, time-boxed ("customer will send it
by Friday").
fusion_plating_configurator → 19.0.14.0.0
fusion_plating_invoicing → 19.0.3.0.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Second attempt at widening the wizard modal after the :has() CSS
approach broke layout. This time using Odoo's built-in
dialog_size mechanism — just drop 'dialog_size': 'extra-large'
into the action's context and Odoo applies its own modal-xl
class, sized for wide content. About 30% wider than the default,
which gives the 10+ line columns breathing room without any
custom CSS.
fusion_plating_configurator → 19.0.13.6.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Reverting the previous wizard-width attempt. The
`.modal-dialog:has(.o_fp_direct_order_wizard)` selector combined
with the fixed width override produced broken layout (modal no
longer rendering correctly).
Better path for widening this wizard is still TBD — the built-in
maximize icon in the modal header already lets users go full-
screen as a workaround until a safe width override lands.
fusion_plating_configurator → 19.0.13.5.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
User complaint: the direct-order wizard's line table was crammed —
"Primary Treatment" showed as "Primary T..." and "Serial Number"
as "Serial Nu..." at the default Odoo modal width (~992px).
Added a dedicated stylesheet that targets the wizard via a new
o_fp_direct_order_wizard class on the form element. The modal
dialog containing the wizard now opens at min(1600px, 95vw) —
wide enough for the 10+ columns (Part, Primary Treatment, Process,
Thickness, Serial Number, Qty, Unit Price, Subtotal, Part Deadline,
WO Group) to fit without truncation on typical desktop displays,
while still adapting to narrower screens.
Also nudged per-cell horizontal padding from Bootstrap's default
to 10px left/right so the columns have a bit more breathing room
inside the wider table.
fusion_plating_configurator → 19.0.13.4.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two small fixes on the direct-order wizard:
1. User reported the Process column from the previous commit didn't
appear on the line list. Root cause: module view definitions
only reload on -u, not on systemctl restart. The earlier ship
bumped the version + ran -u, but the Process column inside the
list view required a fresh view load. Re-running -u now resolves
it (no code change needed for that field).
2. The "+ Add From Prior SO" and "+ Add From Quotes" buttons were
rendering edge-to-edge because their container div used the
default Bootstrap flow (margin-right: 0). Swapped the wrapping
div class from `mb-2` to `mb-2 d-flex gap-2` so Bootstrap lays
the two buttons side-by-side with a consistent 0.5rem gap.
fusion_plating_configurator → 19.0.13.3.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
User asked why the direct-order wizard only showed "Primary
Treatment" and not Process — aren't they the same? They're not,
but the distinction was invisible on the order line until now.
Mental model (preserved here to keep future decisions aligned with
the user's question):
* Primary Treatment (fp.coating.config) = "WHAT coating" (process
type, thickness range, spec reference — the contractual
deliverable).
* Process (fusion.plating.process.node tree) = "HOW we make it"
(the floor-level sequence of operations and steps that WO
generation turns into work).
Each coating carries a default process (recipe_id). Parts can
override that via the Process Composer, storing a part-scoped
clone (default_process_id on fp.part.catalog). Resolution:
part's composed process wins; coating default is the fallback.
Added a computed read-only `effective_process_id` field on
fp.direct.order.line that displays exactly what process will drive
WO generation for the line, plus a one-line `effective_process_source`
showing whether it came from the part ("customised") or the
coating ("default"). Both surfaced on the wizard list and form so
the estimator can verify before confirming the order.
No behaviour change — this is pure visibility. WO generation still
uses the same resolution chain it did before.
fusion_plating_configurator → 19.0.13.2.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two user-reported gaps:
1. The Process Recipes list was about to be flooded by part-scoped
clones as soon as parts started carrying customised processes —
thousands of clones would bury the handful of real shared
templates (General Processing, Anodize, etc.).
Fix: the main Process Recipes action now narrows to
part_catalog_id = False so shared templates stay alone in that
view. A sibling menu "Part Processes" (Plating → Operations →
Part Processes) shows the inverse list — every part-cloned
process, grouped by part — so admins can audit clones without
cluttering the templates list.
Search view gains two toggle filters (Shared Templates /
Part-Scoped) and a "Group by Part" option. The node list gains
an optional "Part" column.
Split across modules: core owns the base search / tree / action
(unchanged); configurator owns all the part_catalog_id-dependent
pieces (filter extensions, list column, narrower domain,
"Part Processes" action + menu). Keeps the dependency direction
clean — configurator always depends on core, never the other way.
2. Added a "Process" smart button to the part form's button box.
Shows either a green check (composed) or "None" (not yet
composed) and opens the part-scoped Composer on click. Gives
users one-tap access from any part form without hunting through
the Process tab.
fusion_plating → 19.0.8.0.0
fusion_plating_configurator → 19.0.13.1.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
User feedback: the Process tab on fp.part.catalog was displaying a
bare template name ("General Processing"), making it impossible to
tell at a glance that the clone belonged to this specific part.
Root clone now inherits the template name with a part-identifier
suffix appended:
"General Processing — 1234567 Rev 2"
Only the ROOT gets the suffix — child nodes keep their clean source
names so the tree-editor canvas doesn't get cluttered.
Suffix logic avoids doubling "Rev": if part.revision is already
prefixed with "Rev " (e.g. "Rev 2"), we don't prepend another one.
Post-upgrade hook backfills existing part-cloned roots that
pre-date this change so users see the new format without having
to re-compose (which would otherwise wipe their customisations).
fusion_plating_configurator → 19.0.13.0.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
User feedback: "Disabled" was confusing; it looked like the step
was turned off entirely when in fact the semantic meant "every job
runs this, cannot be removed". Aligning labels with Steelhead's
own terminology and the mental model the shop floor already uses:
Python Selection values (unchanged: disabled / opt_out / opt_in)
disabled → "Required"
opt_out → "Opt-Out (included by default, can be removed per job)"
opt_in → "Opt-In (excluded by default, can be added per job)"
Tree-editor side panel inline labels match, plus a short helper
line under the dropdown:
"Required — every job runs this step.
Opt-Out — ships included, estimator can remove per job.
Opt-In — ships excluded, estimator can add per job."
Field string also flipped from "Opt In/Out" to "Step Usage" — the
new header reads closer to what the field actually controls.
Column order also flipped so the Opt-Out option appears above
Opt-In — matches the frequency in real recipes (most optional
steps are included by default and sometimes skipped, not the other
way around).
fusion_plating → 19.0.7.4.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two related gaps:
1. loadTree() only auto-expanded nodes when expandedNodes was
completely empty — that was "first-load only" behaviour. After
an import, the subsequent loadTree() found the map populated
and skipped the expand pass entirely, so every freshly imported
node came in collapsed ("2 hidden"). Users had to click each
one open by hand.
Fix: iterate the whole tree on every load and default any node
whose id isn't yet in expandedNodes to true. Nodes the user
explicitly collapsed stay that way (their id IS in the map,
set to false).
2. Added "Expand all" and "Collapse all" buttons to the tree-
editor header so operators can get a full view (or a tight
overview) without clicking node by node. Collapse all keeps
the recipe root expanded — otherwise the canvas goes blank.
fusion_plating → 19.0.7.3.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The import feature appended every imported node to the end of the
target recipe. That's wrong for the common case — General Processing
has Shipping as its last operation, so importing an Electroless
Nickel pack should land BEFORE Shipping, not after it. The user
would otherwise have to click Move Up dozens of times.
Controller: /fp/recipe/node/import_children now accepts
insert_before_id:
null/missing → append at end (default, unchanged)
0 → insert at the start
<positive id> → insert right before that top-level child
Implementation reorders target's top-level children in one pass
after Phase 1 creates the copies (placeholder sequence=0). Phase 2
splits existing vs. new, finds the anchor index in the existing
list, and reassigns sequences 10/20/30/... across the merged list.
Collisions on the old max_seq-based append strategy are eliminated.
JS: state.importInsertBefore drives a new "Insert:" dropdown in the
toolbar with options:
— At the end — (default)
— At the start —
Before <each top-level child name>
Smoke on entech (3-case): insert-before-middle, insert-at-start,
insert-at-end all produce the expected ordering.
fusion_plating → 19.0.7.2.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two bugs reported on the tree editor after the move/import feature
shipped:
1. Card titles truncated to "Contrac…" because .o_fp_re_title had
white-space: nowrap + text-overflow: ellipsis. Swapped to
white-space: normal + overflow-wrap: anywhere so long names
wrap onto multiple lines inside the card. Widened card max-
width 380→460px and bumped min-width 240→260px so wrapped
titles have room.
2. Import-children was flattening the tree — all operations AND
their step children landed at the top level instead of staying
nested under their operations.
Root cause: src_node.copy({'parent_id': new_parent.id, ...})
on a _parent_store model behaved unpredictably — in some runs
the override in copy_vals didn't stick and child recursion
ended up with a wrong parent_id. Rewrote _copy_subtree to use
copy_data() + Node.create() so parent_id is set explicitly and
child_ids / parent_path are stripped (we recurse ourselves).
Smoke verified on entech: General Processing (1 root + 5 ops
+ 7 steps = 13 nodes) imports with hierarchy bit-identical to
source.
fusion_plating → 19.0.7.1.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two gaps closed on the recipe tree editor based on user feedback:
1. Explicit Move Up / Move Down buttons on every non-recipe node
row, driven by a new POST /fp/recipe/node/move_sibling endpoint.
DnD already existed but couldn't reliably move a node above a
sibling when the drop zone overlapped the node being dragged.
The button-based flow sidesteps that entirely and makes "nudge
one slot" a single click.
2. Inline "Import from recipe" toolbar that appears when the
Import button is clicked in the header. User picks a source
recipe from a dropdown (POST /fp/recipe/list, excludes the
current one), toggles "Skip duplicate names", and clicks
Import. POST /fp/recipe/node/import_children deep-copies every
top-level child of the source under the current recipe,
preserving the sub-tree structure. Dedupe is on by default so
re-running the import on an already-populated recipe is a
no-op; users who want to merge identical-named branches can
untick the checkbox.
Controller endpoints:
- /fp/recipe/list (list recipe roots for the picker)
- /fp/recipe/node/move_sibling (swap with neighbour by direction)
- /fp/recipe/node/import_children (deep-copy subtree with dedupe)
Smoke verified on entech: 5-child recipe imported cleanly, dedupe
blocks re-import, sequence swap works.
fusion_plating → 19.0.7.0.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two separate issues were stacking up on the breadcrumb trail:
1. The composer was launching the tree editor with the name
"Process Composer — …" — identical to its own label. The
breadcrumb trail ended up showing "Process Composer / Process
Composer" because both pages claimed the same name. Renamed the
tree-editor instance to "Process Editor — …" so the two pages
read distinctly.
2. Every "Back to part" click pushed a new entry onto the
breadcrumb stack instead of resetting. After one round-trip the
trail looked like "… / Composer / Editor / Part"; after two it
was "… / Composer / Editor / Part / Composer / Editor / Part".
Added clearBreadcrumbs: true to both back paths (composer's
backToPart and tree-editor's onBackToList) so a RETURN action
actually resets the stack.
fusion_plating → 19.0.6.2.0
fusion_plating_configurator → 19.0.12.4.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
When the Recipe Tree Editor is opened from the part-scoped Process
Composer (Sub 3), the composer already passes part_id via the
action context. The editor was ignoring it and routing onBackToList
to the generic Recipes list, stranding the user away from the part
they came from.
Capture ctx.part_id at onMounted, expose a state.fromPart flag, and
branch onBackToList: if part_id is set, open the fp.part.catalog
form; otherwise keep the current Recipes-list behaviour. XML button
label flips "Recipes" → "Part" accordingly so the user knows where
the button will take them.
fusion_plating → 19.0.6.1.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Icon + label now share an inline-flex row with align-items: center,
so both sit on the button's vertical midline regardless of line-
height inheritance.
- Dedicated gap (10px) replaces the me-2 utility so the _hint block's
.fa { margin-bottom: 16px } can't bleed in and push the icon off.
- Icon colour forced to #ffffff to match the button's white label —
contrast against btn-primary green is now clean.
fusion_plating_configurator → 19.0.12.3.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Icon: fa-edit → fa-sitemap (pencil suggests inline editing; the
button actually navigates to a separate tree editor — sitemap
matches the intent).
- Icon spacing: swap the fragile leading-space-in-span for the
Bootstrap me-2 utility so the icon-to-text gap is consistent.
- Label: "Open Tree Editor" → "Open Process Editor" to match the
page title ("Process Composer") and the menu vocabulary the rest
of the product uses.
fusion_plating_configurator → 19.0.12.2.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Process Composer was rendering a white card background on dark-mode
tenants because the SCSS relied on var(--bs-body-bg, #ffffff) — the
Bootstrap CSS variable doesn't flip reliably in Odoo 19's backend,
and the hardcoded fallback kicked in.
Rewrote with the shopfloor token pattern from CLAUDE.md: branch on
$o-webclient-color-scheme == dark at compile time, expose via CSS
custom properties (--fp-composer-card / -border / -panel / -text /
-muted), drop every --bs-* fallback for layout colours.
Cleared the ir_attachment asset cache on entech so both the backend
and web_dark bundles recompile cleanly.
fusion_plating_configurator → 19.0.12.1.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
fp.receiving simplifies to box-count-only (new primary state
machine: draft → counted → staged → closed). Legacy
inspecting/accepted/discrepancy/resolved states stay in the
Selection so existing records load without error but are surfaced
behind a manager-only toggle. New box_count_in field + banner
that tells the receiver "count boxes only — parts are inspected
by the racking crew."
New fp.racking.inspection + fp.racking.inspection.line models —
one record per MO, auto-created by mrp.production.create() with
one line per contributing SO line (qty_expected seeded, qty_found
+ condition filled in by the racking crew when they open the boxes).
State: draft → inspecting → done | discrepancy_flagged (flagged
when any line has a non-ok condition or qty variance). Reopen
restricted to Plating Manager.
WO soft gate: first plating WO button_start raises a UserError
when the MO's racking inspection is still Draft or Inspecting.
Plating Manager bypasses; later WOs are not gated.
fp.delivery gains x_fc_box_count_out. action_mark_delivered calls
_fp_check_box_parity which posts a non-blocking chatter warning
when boxes out ≠ boxes in (resolved via job_ref → MO.origin → SO
→ receiving). Warning only — never blocks shipping.
Menu entry: Plating → Operations → Racking Inspection.
Module version bumps:
fusion_plating_receiving → 19.0.3.0.0
fusion_plating_logistics → 19.0.3.0.0
fusion_plating_bridge_mrp → 19.0.12.0.0 (+depends receiving)
Smoke on entech: 12/12 assertions pass (one gate test skipped —
MO had no WOs to test) including box-count state machine, inspection
auto-create, lifecycle, discrepancy flag, and box-parity chatter.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Receiving simplifies to box-count-only (draft → counted → staged →
closed). New fp.racking.inspection + line models capture the per-part
inspection the racking crew does when they open the boxes, linked to
MO not to receiving. Soft gate on first WO start when the inspection
is still pending (manager override). fp.delivery gains box_count_out;
action_mark_delivered posts a non-blocking chatter warning when
boxes out ≠ boxes in.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Five new boolean flags on res.partner applied to CHILD contacts:
x_fc_receives_certs, _qc, _quotes_so, _invoices, and _is_global_contact.
Single resolver helper res.partner._fp_resolve_notification_recipients
(stream, delivery_location=None) walks location contacts first then
company contacts, returning emails for contacts that opted into the
stream (or flagged themselves global). Falls back to partner.email
when no contact opts in so existing customers keep their exact
pre-Sub-6 routing.
fp.notification.template._dispatch now maps each trigger event to a
stream (so_confirmed→quotes_so, invoice_posted→invoices, shipped→
certs, etc.) and overrides the mail_template's email_to with the
resolved list. fp.delivery passes its delivery_address_id so the
shipped/CoC email routes through location-scoped contacts when they
exist.
Partner form gets a new "Communication Routing" tab on child contact
forms with the 5 flags (hides the per-stream checkboxes when
Global Contact is on, since it overrides them).
fusion_plating_certificates → 19.0.4.0.0 (adds the flag fields)
fusion_plating_notifications → 19.0.5.0.0 (+depends certificates)
Smoke on entech: 11/11 assertions pass including per-stream routing,
delivery-location scoping, zero-flag fallback, email-less skip,
unknown-stream + global behaviour, and case-insensitive dedup.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Five per-contact boolean flags (certs / qc / quotes-so / invoices /
global), native Odoo delivery-location child contacts reused for
per-location routing, and a single resolver on res.partner that the
dispatcher + all mail-send sites call. Fallback to self.email keeps
existing customers bit-identical when no flags are set.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Per-sensor override on fp.tank.sensor.poll_interval_minutes with a
company-wide default (res.company.x_fc_default_poll_interval_minutes,
default 30) exposed in Settings → Fusion Plating → IoT. Single
lookup helper _fp_effective_poll_interval_minutes keeps downstream
call sites simple. Read-only poll_interval_display Char ("30 min
(default)" / "15 min (override)") keeps units unambiguous per user
request.
Ingest endpoint /fp/iot/ingest drops readings that arrive inside a
sensor's effective interval, returning {accepted, skipped} so the Pi
agent can log it. Pi-side interval stays its own concern.
Post-init hook seeds 5 small tanks + 20 big tanks (10 active, 10
inactive) with 1 temperature + 1 pH sensor each → 25 tanks, 50
sensors. Idempotent (keyed by tank.code, with_context(active_test=
False)). Opt-in via ir.config_parameter
fusion_plating_iot.seed_entech_tanks = '1' so a fresh install
elsewhere doesn't auto-seed. Flag set on entech today; 27 tanks / 52
sensors now live (2 pilot + 25 seeded).
Smoke on entech: 14/14 assertions pass including idempotency and
rate-limit conditions.
fusion_plating_iot → 19.0.2.0.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Per-sensor override on fp.tank.sensor.poll_interval_minutes, company-
wide default on res.company, ingest controller rate-limits readings
that arrive inside the effective interval. Seeds entech with 25
tanks (5 small, 20 big — 10 active/10 inactive) and 50 sensors
(temp + pH per tank) as noupdate=1 data so admin edits survive
upgrades.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Four new fields on every sale.order.line, propagated through to MO,
Delivery, and Invoice for end-to-end traceability:
- fp.serial registry (new model in configurator) with smart-button
traceability to Sale Order, MO, Delivery, Invoice, Part. M2O on SO
line; optional; user types a customer serial or clicks Generate
Serial for a sequence-backed one. Reverse O2M links split across
configurator (invoice) / bridge_mrp (MO) / logistics (delivery) so
module load order is respected.
- x_fc_job_number on SO line, auto-sequenced FP-JOB-NNNNN on SO
confirm. Editable — shops can override for customer/legacy schemes.
- fp.coating.thickness (new child of fp.coating.config) with per-
config discrete thickness options; x_fc_thickness_id on SO line
domain-filtered to the line's coating. Auto-clears when coating
changes.
- x_fc_revision_snapshot Char on SO line, frozen from
x_fc_part_catalog_id.revision at save. Protects historical SOs from
later catalog edits. Secondary "Revision" picker on the tree view
lets users switch between prior revisions of the same part number;
the Part M2O still surfaces only is_latest_revision rows.
Reports (CoC, packing slip, invoice, BoL) pick up all four via the
Sub 2 customer_line_header macro — one macro edit, four reports.
Smoke on entech: 11 assertions pass including revision snapshot,
generate-serial button, typed-serial create-on-fly, coating→thickness
domain reset, SO confirm auto job#, and MO traceability carry.
Module version bumps:
fusion_plating_configurator → 19.0.12.0.0
fusion_plating_bridge_mrp → 19.0.11.0.0
fusion_plating_logistics → 19.0.2.0.0 (+depends configurator)
fusion_plating_reports → 19.0.5.1.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
fp.serial registry with smart-button traceability (SO, MO, Delivery,
Invoice, Part), fp.coating.thickness child table per coating config,
four new fields on sale.order.line propagating through to MO /
Delivery / Invoice via existing hooks. Revision picker with latest-
only default + switcher + snapshot Char. Reports pick up all four
via Sub 2's customer-line-header macro.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Checklist group used col=\"4\" which stretched each label+field
pair across a quarter of the sheet, producing a big empty gap
between the two columns. Replaced with the idiomatic Odoo two-
nested-group pattern so each column hugs its labels, removing the
dead space. Same fix applied to Section 3.0 and to the Outcome
blocks on both sections.
fusion_plating_quality → 19.0.2.3.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds a "Contract Review" stat button to fp.part.catalog's button box.
Shows a coloured state badge (green=complete, blue=manager_review,
yellow=assistant_review, muted=dismissed, em-dash when none). Click
routes through action_start_contract_review so it opens the existing
review or lazy-creates one — same behaviour as the banner / tab.
fusion_plating_quality → 19.0.2.2.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- New bulk-toggle actions on fp.contract.review flip all 10 checklist
items in Section 2.0 (and all 11 in Section 3.0) in one click.
Rendered as "Check All" / "Clear All" buttons above each checklist.
User can still tick boxes individually. Buttons hide once the
section is signed (locked).
- Fix QA-005 PDF: replaced `to_text(...)` (not in QWeb context) with
`image_data_uri(...)` for the company logo embed. PDF now renders
with the full colour ENTECH logo (render size 103 KB).
- Smoke test extended: 5 new assertions covering bulk-toggle on/off
and locked-section guard. 17/17 pass on entech.
fusion_plating_quality → 19.0.2.1.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Per-part contract review record (fp.contract.review) gated by a
customer-level toggle, signed in two sections (QA Assistant → QA
Manager), settings-based signer rosters (no new res.groups), banner on
the part form that auto-dismisses once the first MO for the part hits
confirmed. QA-005 Rev. 0 paper form reproduced 1:1 in a QWeb PDF.
Never blocks MO/SO/WO — review is purely an audit artefact.
Smoke test run on entech: 12 assertions pass including the 25-cell
risk matrix parity with the paper form and 22 KB PDF render.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Dedicated fp.contract.review model in fusion_plating_quality, triggered by
a per-customer toggle, two-section QA sign-off (QA Assistant + QA Manager),
settings-based roster (no new res.groups), printable 1:1 QA-005 PDF. Never
blocks MO/SO/WO. Banner auto-dismisses once first MO for the part reaches
confirmed state.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sub 3 (Default Process + Composer per Part) complete:
- Phase A: schema additions (part_catalog_id, cloned_from_id,
treatment_uom on process_node; default_process_id on part_catalog),
opt_in_out label rename, General Processing seed flipped to
noupdate=1
- Phase B: part-scoped Process Composer client action
(fp_part_process_composer) with 3 RPC endpoints + OWL wrapper +
Process tab on part form with Compose button
- Phase C: tree node MO-state palette (green=completed, blue=active,
red=error-only)
All 8 Sub 3 smoke checks green. Phase 1-3 QC smoke + E2E still green.
Sub 2 features untouched.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Add fp_part_composer_controller with 3 JSON-RPC endpoints:
/fp/part/composer/state, /fp/part/composer/templates,
/fp/part/composer/load_template (deep-clones a shared template
into a part-owned tree inside a cr.savepoint, sets
fp.part.catalog.default_process_id atomically)
- _clone_subtree copies name/sequence/opt_in_out/treatment_uom plus
description/notes/icon/color/timing/behaviour/work_center/process_type
and stamps part_catalog_id + cloned_from_id on every node
- Add fp_part_process_composer OWL client action (JS + XML + SCSS):
picks template from dropdown, clones, hands off to existing
fp_recipe_tree_editor via context={recipe_id, part_id}
- Add Process tab on part form with readonly default_process_id
field and Compose button calling action_open_part_composer
- Register new assets in web.assets_backend, bump configurator
version to 19.0.11.0.0
The wizard was calling so.action_confirm() immediately after creating the
sale order, which flipped it from draft to sale state and triggered the
fusion_plating_notifications hook that auto-emails the customer.
Client wants a review step: keep the SO in quotation (draft) so the
user can adjust before the customer sees anything. They manually click
Send (to email the quotation) or Confirm (to convert to sale order,
which intentionally fires the confirmation email).
Changes:
- Remove so.action_confirm() call in action_create_order
- Update docstring + inline comment to reflect manual-confirm flow
- Update the chatter message on the created SO
CLAUDE.md updated to mark Sub 1 + Sub 2 as Shipped.
Verified:
- Static check: wizard.action_create_order contains no action_confirm
- Dynamic check: SO created programmatically stays in draft
- Manual action_confirm() flow still works as designed
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
When Sub 2 Task 26 flipped x_fc_internal_description to required=True,
any programmatic sale.order.line creation that doesn't set the field
fails at the Postgres NOT NULL constraint. Callers include:
- sale_mrp stock-move line creation (doesn't set name either)
- demo seeders
- external integrations
- test scripts
The UI-side onchange populates the field when the user picks a
description template; this hook mirrors that for programmatic callers.
Fallback chain: explicit vals['x_fc_internal_description'] → vals['name']
→ product_id.display_name → '—'. Matches the migration's backfill rule.
Also adds Sub 2 end-to-end smoke test (6 cases, all green):
1. Required-field rejection on part creation
2. Required-field rejection on template creation
3. Template picker populates both SO-line descriptions
4. Cert resolver: part-level override wins over partner
5. display_name renders part_number + revision + name
6. certificate_requirement defaults to 'inherit'
QC Phase 1-3 regression suite remains green after the fix.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Removes the `description` field from `fp.sale.description.template` now
that all readers (reports, wizard, sale line) consume the new
`internal_description` + `customer_facing_description` pair.
- Model: drop `description = fields.Text(...)` declaration
- Migration 19.0.9.0.0 Step 6: `ALTER TABLE ... DROP COLUMN IF EXISTS description`
- Template form/search views: swap `description` for the two new fields
- Seed data: write new fields instead of legacy column (dupes old text into both)
- Direct-order wizard: remove `tpl.description` fallback in both onchange handlers
Entech column dropped via Odoo's auto-schema-sync during module upgrade
(migration step is for fresh installs).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
