- Add model naming convention table (fp.* for new, fusion.plating.* for existing)
- Add fusion_plating_certificates as dedicated module with fp.thickness.reading model
- Fix complexity_surcharge: companion model instead of JSON text field
- Add recipe_id domain constraint [('node_type', '=', 'recipe')]
- Align security groups with existing 4-level privilege hierarchy
- Add currency_id to all monetary models
- Clarify fp.quote.configurator as persistent model with state lifecycle
- Fix canonical model names (fusion.plating.portal.job, fusion.plating.delivery)
- Add auto-population rules for invoice strategy and configurator defaults
- Lighten bridge_mrp deps: gates as mixins in receiving/invoicing modules
- Add deployment strategy for fusion_tasks (same server, not standalone)
- Add data migration section for existing quote request coexistence
- Add work centre mapping note (fusion.plating.work.center ↔ mrp.workcenter)
- Change x_fc_account_hold_date to Datetime for audit precision
- Add bilingual CoC implementation note (QWeb, not ir.translation)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Full ASCII diagram of the end-to-end lifecycle with [DONE] / [NOT BUILT]
tags. Key models quick reference table. 3 remaining gaps: Recipe→WO
generation, account hold check, auto-email package. Architectural
decisions documented for next session.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Links recipes to manufacturing orders via x_fc_recipe_id on mrp.production.
New model fusion.plating.job.node.override stores per-job opt-in/out
decisions for optional recipe steps.
Config wizard (fp.recipe.config.wizard) shows all optional nodes as a
checklist — opt-in steps default unchecked, opt-out steps default checked.
Planner toggles and confirms. "Overrides" stat button on MO form opens wizard.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Documents the full Quote→PO→SO→Recipe+WO→Invoice→Ship→Email workflow
for next sessions. Includes status table, architectural decisions needed,
and component mapping to Odoo models.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Comprehensive instructions for future sessions: module structure,
critical Odoo 19 rules, recipe system architecture, deployment commands
for both servers, Steelhead feature status, and naming conventions.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Icon field is now a selection with 24 curated plating icons. Users pick
from a dropdown with descriptive labels (e.g. "Fire / Bake", "Diamond /
Plating") instead of typing FA class codes.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New opt_in_out selection field (disabled/opt-in/opt-out) matching
Steelhead's Configure OPT IN/OUT feature. Shown in both the form
view and the tree editor side panel.
Time tracking: form view now shows Created, Created By, Last Updated,
Updated By fields. Tree editor side panel shows relative timestamps
down to the second (e.g. "46w 3d 4h 17m 21s ago by Brett Kinzett").
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replaced text input with a clickable 24-icon grid picker for the side
panel. Icons are curated for plating (flask, blast, mask, rinse, bake,
plate, inspect, etc.). When adding a new step, the icon is automatically
guessed from the name via keyword matching (e.g. "Masking" → paint-brush,
"Oven baking" → fire, "Acid Dip" → flask).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Odoo 19 search views: removed <group string="..."> wrapper (invalid),
removed string attr from <search>, removed filter_domain on name field.
Removed unaccent=False from parent_path (unknown param in this version).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New model fusion.plating.process.node with _parent_store hierarchy for
defining reusable plating recipes. Node types: recipe, sub_process,
operation, step. Includes companion model for operator input definitions.
Full OWL tree editor (client action) with:
- Hierarchical tree with connector lines and type-coloured borders
- Click-to-edit side panel with save
- Add/delete child nodes inline
- Drag & drop reorder and reparent
- Theme-aware SCSS (light + dark mode)
- Demo data: Electroless Nickel Plating — Steel Line (30+ nodes)
Backend: 7 JSON-RPC endpoints for tree CRUD, reorder, move, duplicate.
Security: 3-tier ACL (operator read / supervisor write / manager full).
Menu: Process Recipes under Plating > Operations.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
color-mix() in border shorthand was being dropped by the SCSS compiler.
Switched to the same pattern Odoo core kanban uses: split border into
border-width/border-style/border-color with $border-color SCSS variable.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Mixing body-color into transparent produced a nearly-invisible border at
1px. Now mixing 22% body-color into body-bg creates an opaque border
that is guaranteed visible in both themes (~#d0d0d0 light, ~#3a3d41 dark).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
var(--bs-border-color) was nearly invisible against var(--bs-body-bg) in
both light and dark mode. Switched to color-mix(var(--bs-body-color) 20%)
which guarantees visible contrast regardless of theme. Hover darkens to 30%.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Cards now have visible borders and elevation shadow in both light/dark
mode. Column count badge restored to high-contrast white-on-gray.
Added HTML5 drag & drop: users can drag work order cards between work
centre columns. Backend endpoint writes workcenter_id on mrp.workorder.
Drop target columns highlight with the action colour.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Plant overview and process tree SCSS files had 90+ hardcoded hex colors
that broke dark mode. Replaced all with Bootstrap/Odoo CSS custom
properties (--bs-body-bg, --bs-body-color, --bs-border-color, etc.)
matching the pattern already used in fusion_plating_shopfloor.scss.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Audit found that fusion.accessibility.assessment._create_draft_sale_order
hardcoded x_fc_sale_type='direct_private' for ALL accessibility cases —
meaning MOD, ODSP, WSIB, and insurance projects never entered their
respective downstream workflows. The MOD workflow rework I shipped in
fusion_claims 19.0.8.0.3 was effectively unreachable from the portal.
Also: x_fc_authorizer_id never propagated from the assessment to the SO,
the new x_fc_mod_accessibility_specialist_id was orphaned, and there
was no back-reference from sale.order to the accessibility assessment.
Fixes:
- New required field x_fc_funding_source on fusion.accessibility.assessment
(march_of_dimes / odsp / wsib / insurance / direct_private / other)
- _create_draft_sale_order now maps funding_source -> x_fc_sale_type,
copies authorizer_id -> x_fc_authorizer_id, sets accessibility_assessment_id
back-ref, and for MOD cases pre-populates
x_fc_mod_accessibility_specialist_id from sales_rep_id.partner_id
- New accessibility_assessment_id field on sale.order so the back-link
is queryable both directions (previously only assessment->SO existed)
- action_complete now guards against double-completion and missing
funding_source: raises UserError instead of silently creating duplicates
- Expanded fusion.accessibility.assessment.state from 3 to 6 values
(draft/scheduled/in_progress/pending_review/completed/cancelled),
added copy=False, added _expand_states group_expand for kanban
- Booking form at /book-assessment now collects funding_source
(required dropdown) so the path is known before the visit happens
- portal_assessment.py book_assessment_submit accepts funding_source
with whitelist validation (defaults to direct_private if missing)
Deployed to odoo-westin (westin-v19) and odoo-mobility (mobility),
both verified at v19.0.2.8.0 with the new columns present.
The long label 'Handed Off (Client/Authorizer Submitting)' was squeezing
the MOD statusbar on the sale order form — the parenthetical pushed half
the states off-screen behind a '...' overflow indicator. Context about
WHO is handling the submission is already captured in x_fc_mod_submitted_by
and visible in the MOD Documents tab, so the statusbar label does not need
to repeat it.
Deployed to odoo-westin and odoo-mobility, re-ran -u fusion_claims on
both so the ir_model_fields_selection.name row was resynced.
In v19.0.8.0.3 the new handoff_to_client MOD state was inserted between
project_complete and pod_submitted in the Selection list, so it rendered
near the bottom of status dropdowns even though it happens very early in
the workflow. Also forgot to add it to _expand_mod_statuses, so it would
not appear as a kanban column without holding records.
Fixes:
- Move handoff_to_client in the Selection tuple to position 6 (right after
quote_submitted, right before awaiting_funding) — parallel to
quote_submitted as the alternative entry into awaiting_funding
- Add handoff_to_client to the main list in _expand_mod_statuses so it
always appears as a kanban column
- Add handoff_to_client AND awaiting_funding to statusbar_visible on the
sale_order form view (awaiting_funding was also missing before)
Deployed to odoo-westin (westin-v19) and odoo-mobility (mobility).
Re-ran -u fusion_claims on both so Odoo resynced the Selection
sequence column. Verified: both databases now show sequence 0..15 with
handoff_to_client at sequence 5, identical between servers.
Reworks the March of Dimes workflow to match reality: the OT does their own
disability assessment and provides the VOD letter; our accessibility specialist
then visits to produce the proposal/drawings/quote; and the application can be
submitted by us (internal), the client, or the authorizer themselves. The old
workflow flattened all this into one assessment state with a dead-end
funding_denied and no document tracking.
Data model (13 new sale.order fields):
- 5 new document binaries + filenames: VOD letter, Application Form (filled),
Notice of Assessment, Property Tax, Proposal Document
- x_fc_mod_submitted_by Selection (internal/client/authorizer)
- x_fc_mod_handoff_date, x_fc_mod_vod_requested_date
- x_fc_mod_accessibility_specialist_id (m2o res.partner — internal or external)
- x_fc_mod_previous_status_before_hold (for proper resume)
- x_fc_mod_funding_denial_reason (captured via wizard)
Settings (4 res.company fields + res_config_settings mirrors):
- x_fc_mod_application_form (blank) + filename
- x_fc_mod_vod_form (blank) + filename
- x_fc_mod_followup_assignee_mode (office_contact / sales_rep)
- x_fc_mod_followup_office_contact_id
res.partner: added 'accessibility_specialist' to x_fc_contact_type.
State machine:
- New state handoff_to_client between quote_submitted and awaiting_funding,
used for paths B/C (client or authorizer submits themselves)
- Fixed action_mod_on_hold to save x_fc_mod_previous_status_before_hold
- Fixed action_mod_resume to restore previous status (was hardcoded to
in_production, losing context for cases held earlier)
4 new wizards:
- mod_submission_path_wizard — chooses submitted_by, auto-fires VOD request
email on first switch to 'internal'
- mod_funding_denied_wizard — captures denial category + reason
- mod_resubmit_wizard — revises + resubmits denied cases (with optional
doc clearing)
- mod_submission_confirmed_wizard — records client/authorizer confirmed
submission, advances to awaiting_funding
8 new action methods:
- action_mod_set_submission_path, action_mod_request_vod,
action_mod_handoff_to_client (validates docs, fires handoff email),
action_mod_confirmed_submission, action_mod_resubmit_from_denied,
action_mod_cancel_from_denied, action_mod_reopen_cancelled
- action_mod_funding_denied now opens the denial wizard
3 new email methods + 2 existing fixes:
- _send_mod_vod_request_email — auto-attaches blank VOD form from company
settings, sent to authorizer when we are handling submission
- _send_mod_handoff_email — two templates (client vs authorizer), attaches
proposal + drawing + blank MOD Application Form
- _mod_company_attachment helper for building attachments from company Binary
- Fixed _send_mod_assessment_completed_email to include authorizer
- Fixed _send_mod_pod_submitted_email to include client
New cron:
- _cron_mod_handoff_followup (daily 09:00) — creates mail.activity for office
to confirm MOD submission. Assignee via company setting (office contact or
sales rep). Uses existing rolling-window cap (2/month per order).
Views:
- sale_order form: new status-bar buttons (set path, request VOD, handoff,
confirm, resubmit, cancel, reopen), new document section in MOD Documents
tab with submission-path tracking, denial details, hold history
- res_config_settings: new MOD blank forms upload + assignee config
Deployed to odoo-westin (westin-v19) and odoo-mobility (mobility). Pre-deploy
FK cleanup from earlier session means mobility updated cleanly without
workaround. HTTP 200 on both, cron verified active, all new fields present.
Workflow (from the FigJam ADP board):
- 9 new ADP action methods to wire up the orphan states that the board
showed had no entry or no exit path: put_on_hold, withdraw, mark_denied,
mark_rejected, mark_needs_correction, cancel, reopen_cancelled,
reopen_expired, resubmit_from_denied.
- 12-month auto-expire cron (_cron_adp_expire_approved) configurable via
fusion_claims.adp_approval_expiry_months, runs daily at 03:00.
- 3 new recovery buttons in the ADP form view (Reopen cancelled, Reopen
expired, Resubmit from denied) in both the primary status bar and the
secondary details panel.
Email (from the 2026-04 email audit):
- 6 new ADP stage email methods via a shared _adp_send_stage_email helper:
assessment_scheduled, assessment_completed, application_received, accepted,
cancelled, expired. Each has a matching dispatch entry in write().
- _send_rejection_email now includes the client (was authorizer-only).
- _send_accepted_email excludes the authorizer per the new rule: "Accepted"
is a passive intermediate state with no authorizer action required.
- _send_ready_for_delivery_email excludes the authorizer: operational
scheduling, not delivery confirmation. Authorizers are notified at
case_closed when the product is actually delivered.
- action_adp_put_on_hold and action_adp_withdraw now fire their matching
email methods so direct action-method calls get the same notifications
as the status_change_reason_wizard path.
Authorizer notification rule (locked in for this update):
Send to authorizer ONLY for initial involvement (assessment/submit/
resubmit), delivery confirmation (case_closed), and problem states
(rejected, denied, needs_correction, withdrawn, on_hold, cancelled,
expired). Skip for billing, payment, ready_delivery scheduling, and
passive intermediates (accepted).
Scope: ADP + ADP/ODSP only. MOD workflow emails reverted and deferred
to a separate update.
Deployed to odoo-westin (westin-v19) and odoo-mobility (mobility).
Pre-existing stock_route_warehouse FK orphans on mobility worked around
by verifying fusion_claims transaction committed before container restart.
Two daily MOD crons were fighting each other. _cron_mod_schedule_followups
created a mail.activity on every MOD order in quote_submitted/awaiting_funding;
_cron_mod_escalate_followups unconditionally deleted the activity after
sending its one-time reminder email. The activity was recreated every day
in a tight loop with no per-period cap — a legitimate 2-4 month wait for
a MOD funding decision would generate dozens of activity churn events and
a bulk email burst the first time the escalate cron ran against a backlog.
Fix:
- New fields x_fc_mod_followup_month_count / _month_start / _cap_notified
(copy=False) track a rolling window per order.
- New config params mod_followup_max_per_month (default 2),
mod_followup_window_days (30), mod_followup_max_per_cron_run (10).
- _send_mod_followup_email resets the window after 30 days, refuses to
send past the cap, and posts a one-shot chatter note explaining why.
- _cron_mod_schedule_followups no longer recreates the activity when the
cap has been hit and stops daily-bumping x_fc_mod_next_followup_date.
- _cron_mod_escalate_followups processes oldest-deadline-first with a
per-run throttle, only unlinks the activity on a successful send so
humans can still action capped cases manually.
- write() resets the rolling counters on any real MOD status change.
Deployed to fusion_claims v19.0.8.0.1 on odoo-westin (westin-v19,
36 affected orders) and odoo-mobility (mobility, 2 affected orders).
Pre-fill image field only for NEW variants. Already-synced variants
get an empty image field — existing WC image is kept unless the user
actively uploads a new one in the wizard.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Added 'Default' toggle column in variant push wizard. First variant is
pre-selected as default. User can change it. The default variant's
attribute values are set as WC product's default_attributes using
WC attribute IDs.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Image endpoint was returning base64 text instead of decoded binary.
Now properly decodes base64 from Odoo Binary field and detects actual
content type from magic bytes (JPEG, PNG, GIF, WebP).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Product image URL was serving placeholder because writing to image_1920
doesn't work for variants (computed field). New approach:
1. Store image in wizard line table (attachment=False, bytea column)
2. Serve directly via /woo/image/{line_id}/{filename} endpoint
3. WC downloads real image data from this URL
4. Also saves to image_variant_1920 for Odoo reference
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Binary field with attachment=True (default) stores in ir.attachment
which doesn't work reliably for transient model inline list records.
Set attachment=False to store in the woo_variant_push_line table directly.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Image wasn't persisting because transient model write was in the same
transaction. Added cr.commit() after saving image to ensure it's
available when WC downloads it. Added size/type logging to trace
image data flow.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
