Commit Graph

7 Commits

Author SHA1 Message Date
gsinghpal
091f98e1f9 changes 2026-05-18 22:33:23 -04:00
gsinghpal
4e0b74d7ae feat(jobs): Sub 14 — configurable workflow state bar (Path B)
Replaces the generic Draft/Confirmed/In Progress/Done statusbar with
a shop-configurable list of plating-specific milestones. Bar advances
automatically as recipe steps complete; no manual button clicks.

What ships
==========

* New model: fp.job.workflow.state
  Catalog of milestones (name, code, sequence, color, triggers).
  Triggers can be:
    - trigger_default_kinds: "receiving,inspect" matches by step.default_kind
    - trigger_first_step_started: any wet/bake/mask/rack step started
    - trigger_all_steps_done: every non-cancelled step in done/skipped
    - block_when_quality_hold: held back while NCR/hold open
  Plus per-recipe-node override (see below).

* Default 7-state seed (data/fp_workflow_state_data.xml):
    Draft → Confirmed → Received → In Progress → Inspected → Shipped → Done
  noupdate=1 so per-shop edits survive module upgrade.

* Recipe-side trigger field on fusion.plating.process.node:
    triggers_workflow_state_id (Many2one, optional)
  Wins over default_kind matching. Lets the recipe author pin a
  specific step as a milestone trigger even when default_kind isn't
  set or doesn't match. Exposed in the Recipe Tree Editor properties
  panel (dropdown sourced from the catalog).

* fp.job.workflow_state_id (computed, stored)
  Iterates the catalog in sequence order; lands at the highest passed
  milestone. Recomputes on step state / kind / recipe_node / quality
  hold changes. Replaces fp.job.state on the form's statusbar.

* Settings UI: Configuration > Workflow States
  Standard list+form pages so admins can add / edit / deactivate
  states. Manager-group write permission, supervisor read.

What this does NOT do
=====================
  * Doesn't drop fp.job.state — that field still drives the internal
    state machine (button_confirm, action_cancel, etc.). Only the
    UI statusbar is reassigned.
  * No migration for existing jobs — they auto-recompute on next read
    because workflow_state_id is a stored compute with the right
    api.depends. Existing WH/JOB/00342 will display its current
    workflow state on next page load.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-03 23:39:38 -04:00
gsinghpal
13e300d90e changes 2026-04-28 19:39:37 -04:00
gsinghpal
d9f58b9851 changes 2026-04-26 15:05:17 -04:00
gsinghpal
7f84e66b72 feat(jobs): finish original plan — Job Margin, polish, legacy hide
Three batched changes that close out the original 10-phase
migration plan.

1. Phase 5 — Job Margin report bound to fp.job (replaces the
   mrp.production-bound report_wo_margin). Per-step labour cost
   table + margin summary using existing fp.job.step.cost_total
   from Phase 1.

2. Polish:
   - Real implementations for fp.job.step.button_pause,
     button_skip, button_cancel (was NotImplementedError stubs).
     button_pause closes the open timelog and sums duration_actual,
     mirroring button_finish; button_skip/cancel transition state
     with UserError guards.
   - Explicit ondelete= policies on fp.job's cross-module Many2ones
     (part_catalog/coating restrict, customer_spec/portal/delivery
     set null) — was implicit set null.
   - Standard Nexa Systems author/website/maintainer/support block
     on fusion_plating_jobs manifest, suppressing the install
     warning.

3. Legacy hide:
   - New 'Plating Legacy Menus' group (group_fusion_plating_legacy_menus)
     — nobody in it by default.
   - Old shopfloor Manager Desk + Plant Overview + Tablet Station
     menus restricted to that group, hiding them from operators
     now that the native equivalents under 'Plating Jobs (Native)'
     exist. (Note: ir.ui.menu uses group_ids in Odoo 19, not the
     deprecated groups_id alias.)

Manifest 19.0.2.4.0 → 19.0.3.0.0. fusion_plating_shopfloor added
to depends so the legacy menu xmlid references resolve at install
time.

Part of: native job model migration (spec 2026-04-25)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-25 04:49:44 -04:00
gsinghpal
4c68327b9c feat(jobs): add fp.job.node.override for per-job opt-in/out decisions
Mirror of fusion.plating.job.node.override from bridge_mrp, but
bound to fp.job. bridge_mrp's version stays alive for legacy MO
flow during the migration. Both coexist.

Adds override_ids One2many to fp.job via _inherit, plus
unique(job_id, node_id) constraint.

Note: spec-suggested _sql_constraints syntax is deprecated in
Odoo 19 ("Model attribute '_sql_constraints' is no longer
supported, please define model.Constraint on the model"). Used
the new class-attribute form: _unique_job_node = models.Constraint(...).
Verified the UNIQUE index is created on the table.

3 new tests: create, uniqueness, one2many backref.

Manifest 19.0.1.1.1 -> 19.0.1.2.0.

Part of: native job model migration (spec 2026-04-25)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-24 23:12:53 -04:00
gsinghpal
4341a03891 feat(jobs): add fusion_plating_jobs module skeleton (Phase 2 Task 2.1)
Empty module that will host the native job bridge during Phase 2
of the migration. Coexists with fusion_plating_bridge_mrp during
the migration period — both can be installed simultaneously
without conflict.

Depends on:
- fusion_plating (fp.job, fp.job.step, fp.work.centre from Phase 1)
- fusion_plating_configurator (fp.part.catalog, fp.coating.config)
- fusion_plating_portal (fusion.plating.portal.job)
- fusion_plating_logistics (fusion.plating.delivery)
- fusion_plating_quality (fusion.plating.customer.spec)
- fusion_plating_certificates (fp.certificate)

These deps are why these fields couldn't live in fusion_plating
core (would invert the dep graph). All cross-module fields on
fp.job and fp.job.step land here via _inherit in subsequent tasks.

auto_install=False — opt-in only.

Part of: native job model migration (spec 2026-04-25)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-24 22:55:04 -04:00