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>
The wizard's binary image field wasn't being saved to the product.product
record, so the public URL returned the default placeholder. Now saves
line.image → variant.image_1920 first, then generates the URL with a
cache-busting timestamp. Only includes image in WC data if the wizard
line has an actual image uploaded.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
WooCommerce requires a file extension in image src URLs to determine
file type. Added filename.png to all Odoo image URLs. Also fixed
variable name ordering bugs where img_name was used before defined.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
WC consumer key cannot auth against /wp/v2/media (401). Instead, pass
Odoo's public image URL in the product/variation data and let WC
download it directly from {odoo_base}/web/image/product.product/{id}/image_1920.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
WooCommerce silently ignores attribute 'name' on variation updates —
requires 'id' (the WC attribute ID). Built a lookup map from the
parent product's wc_attributes and use 'id' in all variation payloads.
Fixed in all 3 files: variant push wizard, product creation wizard,
and product map direct push.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Odoo web client strips readonly field values during record creation,
so already_synced/wc_variation_id/map_id were always NULL. Removed
readonly from Python model, added force_save="1" in XML view to ensure
these tracking fields are persisted through the wizard lifecycle.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Archived variants (active=False) and variants with no attribute values
were being included, causing WC 400 errors. Now only active variants
with attribute assignments are shown and pushed.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Onchange wasn't firing when wizard opened via context defaults. Moved all
variant line population to default_get so lines are pre-filled immediately.
Added debug logging to trace new vs update classification.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Update path sends attributes per variation (was missing, causing
"Any COLOR..." on WC)
- Sets default_attributes on parent product (first variant's values)
- Better API error logging with response body
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Already synced variants are editable — change price, SKU, image and click
Save & Sync to update them on WooCommerce. New variants are created,
existing ones updated in a single action. Button shows on all products
with variants (purple for new, grey for already synced).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replaced direct push with a wizard that shows all variants in an editable
table. User can review/edit standard price, sale price, SKU, and image
per variant before pushing. Include/exclude toggle per variant. Already
synced variants shown for reference. Geo-tags images if configured.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Removed separate Variants column — button now appears right next to the
Odoo product name so it's visible without scrolling.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When a mapped product is simple on WC but has variants in Odoo, a purple
"N variants" button appears in the Variants column. Clicking it:
1. Converts the WC product from simple to variable
2. Creates WC attributes and terms from Odoo attribute lines
3. Creates a WC variation for each Odoo variant with price/SKU/stock/tax/image
4. Creates woo.product.map records for each variation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
