docs(jobs): split fp.job §5.1 fields by module ownership (Task 1.4)

Originally Task 1.4 was to add all spec §5.1 extension fields to
fp.job in core. The dependency-graph audit during implementation
revealed that 6 of those fields point to models in dependent
modules (configurator, quality, portal, logistics, bridge_mrp).
Adding them in core would invert the dependency graph.

Spec §5.1 now has a Module column. Core-safe fields stay in
fusion_plating/models/fp_job.py; cross-module fields are deferred
to their owning modules via _inherit = 'fp.job' in Phase 2.

Plan Task 1.4 narrative updated to reflect the reduced scope.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
gsinghpal
2026-04-24 21:54:35 -04:00
parent e4111ad000
commit f7a4cba5a8
2 changed files with 75 additions and 73 deletions

View File

@@ -453,7 +453,10 @@ Create `fusion_plating/data/fp_job_sequences.xml`:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<odoo>
<!-- noupdate="1" is REQUIRED — without it, every -u fusion_plating
resets number_next back to 1, which corrupts the live sequence
on every module update. Matches the convention in fp_sequence_data.xml. -->
<odoo noupdate="1">
<!-- Sequence for fp.job. Format: WH/JOB/00001 onwards.
Migrated mrp.production records keep their WH/MO/... names. -->
<record id="seq_fp_job" model="ir.sequence">
@@ -513,11 +516,20 @@ Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>"
---
### Task 1.4: Add SO/origin/extension fields to `fp.job`
### Task 1.4: Add core-safe extension fields to `fp.job`
The full field list from spec §5.1 — added in chunks so each commit is reviewable.
**Scope reduction (2026-04-25):** Originally this task added all spec §5.1 fields.
But the dependency audit during Task 1.4 implementation revealed that 6 of those
fields point to models in modules that depend on `fusion_plating` core (configurator,
quality, portal, logistics, bridge_mrp). Adding them in core would invert the
dependency graph. **Per the updated spec §5.1**, those fields are deferred to their
owning modules via `_inherit = 'fp.job'` and re-bundled by `fusion_plating_jobs` in
Phase 2.
- [ ] **Step 1: Add SO + recipe + portal/delivery fields**
This task now lands ONLY the fields whose target models are reachable from core's
existing `depends` (sale_management → sale → account, and our own process.node):
- [ ] **Step 1: Add SO + recipe core-safe fields**
Modify `fusion_plating/models/fp_job.py` — add fields after `company_id`:
@@ -528,19 +540,6 @@ Modify `fusion_plating/models/fp_job.py` — add fields after `company_id`:
'job_id', 'line_id',
string='Source SO Lines',
)
part_catalog_id = fields.Many2one(
'fp.part.catalog',
string='Part',
index=True,
)
coating_config_id = fields.Many2one(
'fp.coating.config',
string='Coating Configuration',
)
customer_spec_id = fields.Many2one(
'fusion.plating.customer.spec',
string='Customer Spec',
)
recipe_id = fields.Many2one(
'fusion.plating.process.node',
string='Recipe',
@@ -551,26 +550,22 @@ Modify `fusion_plating/models/fp_job.py` — add fields after `company_id`:
string='Start at Node',
help='Rework: start the job at this recipe node (skip earlier).',
)
portal_job_id = fields.Many2one(
'fusion.plating.portal.job',
string='Portal Job',
)
delivery_id = fields.Many2one(
'fusion.plating.delivery',
string='Delivery',
)
invoice_ids = fields.Many2many(
'account.move',
'fp_job_account_move_rel',
'job_id', 'move_id',
string='Invoices',
)
qc_check_id = fields.Many2one(
'fp.quality.check',
string='Active QC Check',
)
```
**Deferred to bridge modules (DO NOT add in this task):**
- `part_catalog_id`, `coating_config_id` → owned by `fusion_plating_configurator`
- `customer_spec_id` → owned by `fusion_plating_quality`
- `portal_job_id` → owned by `fusion_plating_portal`
- `delivery_id` → owned by `fusion_plating_logistics`
- `qc_check_id` → owned by `fusion_plating_jobs` (Phase 2; the underlying model
`fusion.plating.quality.check` currently lives in `fusion_plating_bridge_mrp`)
- [ ] **Step 2: Add cost rollup fields (computed)**
Append: