All WorkStep models merged into WorkStep

Complete consolidation scope

WorkStepRecord is an abstract base with no standalone physical table; its fields are inherited today and move directly onto the unified model. Repository, revision, occurrence, entry, demand and assignment classes already share WorkStep storage; their separate model definitions are now marked for retirement. WorkStepPhase and WorkStepReferenceDetails are the additional separate tables covered by this decision.

Record roles and relationships

Unified WorkorderMaster (child) → WorkStep execution
Occurrence → Execution → Entries / definitions / material and resource demand
Resource request → Resource assignment
Execution entry → Component selection
Repository → Immutable repository revision
Phase → Related phase; reference details → Owning execution

Retain RecordKind and the existing numeric values; add reviewed Phase/ReferenceDetails kinds as needed. One model does not collapse repeated occurrences, allocations, signed entries or version records into a single row. Preserve existing self-reference IDs and enforce valid role pairs, ownership, no self/cyclic parents and filtered uniqueness.

The selected task supplies the maintenance phase. MaintenancePhase and PhaseCode are Dropped from the WorkStep proposal. Map historical phase assignments to task-owned definitions and preserve applicability, revision context and related-phase/counterpart behavior during later implementation. Remaining phase relationships still require review. Reference details retain one-to-one ownership and existing AutoInclude/API behavior during endpoint adaptation. Only Execution rows count as executable steps in progress and manpower reports.

Fields and validation

All 105 mapped field names are represented once, including inherited audit/revision fields. Existing ActionType maps to EntryType. Nullable storage supports different record roles; required role values remain enforced by validation and constraints. Keep measurement identifiers, units and limits, demand versus actual usage, independent inspection/signature evidence, repository revision immutability and component-result behavior.

Adoption after complete review

1. Implement one WorkStep entity with the combined field set, adapting typed-role query/controller/service behavior to RecordKind.
2. Inspect live schemas; preserve or remap phase, reference, occurrence, entry, resource and repository identities, audit/revision links, self references and incoming foreign keys.
3. Backfill phase/reference values and roles, reconcile historical standalone tables and replace relationship targets while preserving cardinality and immutable records.
4. Adapt frontend forms, lookups, repository editing, phase planning, execution, signing, resources/material fulfillment and reporting to the unified entity.
5. Validate field coverage, enum/default compatibility, role constraints, ownership and lifecycle queries before applying a reviewed migration or retiring physical tables.

Resolved workflow and field overlaps

Review decisions only. Backend services, APIs and database adoption remain pending complete review.

Component actions and identity combinations

HTML proposal only. Existing backend validation and movement behavior are unchanged; unknown identities and extended actions await implementation after complete review.

Keep EntryType for the overall entry category and ComponentActionType for the component operation. Use separate source and destination child WorkStep rows linked to the same owning action through OwnerRecordId and WorkStepId. Each row uses the standard ConfigurationMasterId, ConfigurationId, PartId and RotableId fields, with ComponentActionRole identifying Source/Destination or Removed/Installed. Multiple units use additional separate child rows. PartNumber remains a snapshot; UndefinedPartNumber and UndefinedRotableNumber capture unresolved identities. The four From/To configuration and part fields are Dropped in this HTML proposal.

Proposed validation and action rules

• Proposed actions: Install, Remove, Update, Replace, Swap, Inspect, Repair, Overhaul, Test, Service, Adjust, Modify, Calibrate, Other. Preserve existing Install=1 and Remove=2; explicitly assign new values during adoption.
• Require ComponentActionType for component-operation entries and ComponentActionRole for their component-identity child rows. EntryType still controls time, measurement, signing and other non-component entries.
• Use either PartId or UndefinedPartNumber for part identity, and either RotableId or UndefinedRotableNumber when a serialized unit is required. Resolve known rotables to their saved PartId; reject mismatches, empty UUIDs and whitespace-only undefined numbers.
• Install requires the destination position; Remove requires the source position. Update/Inspect/Repair/Overhaul/Test/Service/Adjust/Modify/Calibrate do not imply an installation or removal by themselves.
• Replace uses Removed and Installed child identity rows under the same owning action. Swap requires complete linked source/destination movements for both units and positions; validate and apply the operation atomically.
• Where quantity applies it must be positive; a row selecting an individual serialized unit represents one unit. Preserve applicable material-demand and resource-request quantity rules.
• Unresolved numbers may be captured for planning or identification. Final stock/configuration mutation requires resolved master IDs, position compatibility, action authorization and execution validation; undefined text is not a saved inventory link.
• Resolve identities through a reviewed operation that preserves the originally recorded text and audit evidence. Define paired-action ownership and duplicate checks before implementation; backend behavior is unchanged today.
• Represent source and destination as separate linked WorkStep rows with the same standard identity fields. Never collapse both sides into a single field value on one row. A remove-only action needs its source row; an install-only action needs its destination row.
• Software changes also use source and destination rows with PartId for the old and new software part and ConfigurationId for the applicable software position. Preserve source/target distinction, required target, different-part checks and allowed-position validation during adoption.
• Backfill each legacy FromConfigurationId/FromPartId and ToConfigurationId/ToPartId pair into its corresponding source or destination row. Preserve existing identity and history, link the paired rows, and validate paired replacement/swap/software changes atomically before retiring legacy columns. Backend/database implementation remains deferred.

Template steps in WorkStep

WorkTemplateItem is Dropped in this proposal. Backend classes and physical tables remain unchanged pending complete review.

WorkTemplateMaster owns reusable TemplateStep-role WorkStep rows through WorkTemplateMasterId. Template steps can have parent/child instructions and structured planned material/resource demand. Issuing creates independent executable WorkStep rows owned by a WorkorderMaster, with copied definitions and demands and preserved template/source revision provenance.

Ownership and issuing rules

• WorkTemplateMasterId is a proposed foreign key to WorkTemplateMaster.Id. Require a saved owner for TemplateStep rows. Restrict deletion of referenced masters until definition ownership and historical use are reconciled.
• Append TemplateStep to RecordKind without changing existing role values. Exclude definition rows from execution progress, live booking, stock movements and signing queries.
• TemplateStep children use OwnerRecordId for hierarchy; planned material/resource rows use WorkStepId to identify their owning definition. Validate same template context, allowed role pairs, no self/cyclic parents and ordering.
• Issuing clones the full selected instruction tree and its planned demands, creates new execution IDs, remaps parents, and assigns the owning workorder. Never use the same row for reusable instructions and actual execution.
• Preserve exact approved template/repository revision and copied content for issued work. WorkTemplateRevisionId remains Dropped in the WorkStep proposal; replacement revision provenance remains an adoption review item rather than silently restoring that field.
• Unpack legacy parts/resources JSON without dropping quantities, units, request attributes or repeated rows. The previously Dropped WorkStep JSON fields remain Dropped.
• Retire WorkTemplateItem model/table only after the reviewed row migration, ownership/provenance mapping and issuing/query adaptation are implemented. This update changes HTML/metadata only.