Files

gsinghpal 152ed86c3a feat(thickness): single Char range field — drop fp.recipe.thickness picker

Per client direction: every order is a thickness RANGE (e.g.
"0.0005-0.0008 mils" or "5-10 mils"), never a single value. The
old picker model (fp.recipe.thickness with a single 'value' Float)
was modelling the wrong concept and overcrowding the order entry
UI. Replaced with one free-text Char field that auto-fills from
last-used or part default.

DELETED entirely:
- fp.recipe.thickness model (file + view + ACL + manifest entry)
- recipe.thickness_option_ids One2many (the picker source)
- "Thickness Options" inline list on the recipe form
- sale.order.line.x_fc_thickness_id (M2O picker)
- account.move.line.x_fc_thickness_id
- fp.delivery.x_fc_thickness_id
- fp.direct.order.line.thickness_id

ADDED:
- sale.order.line.x_fc_thickness_range (Char) — operator types range
- account.move.line.x_fc_thickness_range — for invoice rendering
- fp.delivery.x_fc_thickness_range — for packing slip
- fp.direct.order.line.thickness_range — for the wizard
- fp.part.catalog.x_fc_default_thickness_range — part default

AUTO-FILL CHAIN (sale.order.line + wizard line):
1. Operator already typed → keep
2. Most recent SO line for (this part, this customer) with a
   non-empty thickness_range → copy that
3. part.x_fc_default_thickness_range → copy
4. Blank — operator types

Implemented as both an @api.onchange (interactive) AND a
create() override (programmatic — wizard, sale_mrp bridge,
imports). Same logic in both paths.

WIZARD push-to-defaults: when "Save as Default" toggle is ticked
on a wizard line, persist the line's thickness_range to
part.x_fc_default_thickness_range so future first-customer orders
get a sensible starting point.

REPORTS: customer_line_header.xml + report_fp_wo_sticker.xml now
print the Char range as-typed (no display_name lookup needed).

KEPT (admin documentation only — doesn't affect order entry):
- recipe.thickness_min, thickness_max, thickness_uom on the recipe
  root: documents the recipe's CAPABILITY range. No UI gate; just
  for spec authors to record what the chemistry can produce.

JOB GROUPING: fp.job auto-create groups SO lines by (recipe, part,
spec, thickness, serial). Updated to key on the thickness_range
Char (stripped) instead of the deleted thickness_id integer.

DB cleanup: --update=base ran on the upgrade, dropping the
fp_recipe_thickness table + the four x_fc_thickness_id columns.
Existing data was already nulled in earlier dev work.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-15 08:54:40 -04:00

data

folder rename

2026-04-16 20:53:53 -04:00

models

feat(thickness): single Char range field — drop fp.recipe.thickness picker

2026-05-15 08:54:40 -04:00

security

folder rename

2026-04-16 20:53:53 -04:00

static/src/scss

folder rename

2026-04-16 20:53:53 -04:00

views

changes

2026-04-28 19:39:37 -04:00

__init__.py

folder rename

2026-04-16 20:53:53 -04:00

__manifest__.py

feat(thickness): single Char range field — drop fp.recipe.thickness picker

2026-05-15 08:54:40 -04:00

README.md

folder rename

2026-04-16 20:53:53 -04:00

README.md

Fusion Plating — Logistics

Part of the Fusion Plating product family by Nexa Systems Inc.

Adds pickup & delivery management on top of the fusion_plating core:

Vehicle master — insurance, registration, service, TDG status, home facility, current driver
Driver tracking — extends hr.employee with licence class, licence expiry, TDG certification and expiry (x_fc_* fields)
Pickup requests — customer-initiated pickup of parts to be processed, with full state machine (new → scheduled → en_route → picked_up → received)
Deliveries — scheduled delivery of finished parts back to the customer (draft → scheduled → en_route → delivered / refused / returned)
Routes — combine pickups and deliveries into a single run for one driver and vehicle, with drag-to-reorder stops, calendar view, and total km tracking
Chain of custody — append-only audit trail written automatically as pickups and deliveries move through their lifecycle
Proof of delivery — recipient signature, photos, GPS, delivery timestamp

Dependencies

fusion_plating (core)
hr
mail

Works on both Odoo Community and Enterprise. The Enterprise fleet module is not required — the vehicle master is a lightweight CE-compatible model sized to what a plating shop needs.

Security

Reuses the core fusion_plating groups (Operator / Supervisor / Manager / Administrator) via the res.groups.privilege mechanism. No new groups are defined by this module.

Operators: read-only on all logistics records
Supervisors: read / write / create on routes, deliveries, pickup requests, vehicles, route stops, custody events, PODs
Managers: full CRUD (adds unlink)

Multi-company isolation is enforced by global ir.rule records on every new model.

Adds a Logistics section under the Plating app menu with:

Pickup Requests
Deliveries
Routes
Chain of Custody
Proof of Delivery

Adds Vehicles under Plating → Configuration.

Field naming

New dedicated models use the fusion.plating.* namespace consistent with the core module.
Extensions of base Odoo models (hr.employee) use the x_fc_ prefix per the Fusion Central convention.

Odoo 19 compliance

res.groups.privilege is reused from the core module — no category_id on res.groups.
No users field on groups.
All models inherit mail.thread / mail.activity.mixin via the _inherit list.
<chatter/> tag used in form views.
SCSS is theme-aware — no hardcoded colours, only CSS custom properties from Odoo / Bootstrap, and color-mix() for semantic tints.

README.md

Fusion Plating — Logistics

Dependencies

Security

Menu

Field naming

Odoo 19 compliance