Component tables: business coverage
Source review · 10 October 2026 · 34 tables
7 shared counterparts · 22 partial overlaps · 5 dedicated functions. A shared counterpart supplies substantial replacement behavior; it does not establish completed migration or full parity. All 34 legacy classes still have their own table mappings in the inspected source. No review badges, backend models or database tables were changed by this review.
The clearest consolidation is the seven component shop scheduling tables into the common ProductionPlan family. ComponentMaintenanceTaskGroup remains mapped despite its Dropped review badge. Measurement validation uses shared code but still consumes component definitions/formulas. Reporting-field coverage for damage/findings does not transfer their closure or release checks.
34 tables
| Component model / function | Coverage and target tables/models | Existing business coverage | Remaining work / treatment |
|---|---|---|---|
| ComponentBlankLabelPrintJobRequest, print and track blank component labels. | Dedicated ComponentBlankLabelPrintJobs; WorkorderPrintJobs is only a related printing feature. | The component report endpoint prints labels and records PrintedAt/PrintStatus. | Workorder print jobs do not supply the blank-label type, printer/template and owner-independent quantity workflow. Keep a label-print record or build a shared print-job service. |
| ComponentMaintenancePartitionProject subdivisions and component repair work with hold/pause lifecycle. | Partial WorkorderMaster + WorkStep + Maintenance.DefectDamageReports/DefectDamageDetails | Header asset, facility, dates and work fields overlap; shared defect reports cover the reported-condition text. | Partition types, project ownership, multiple partitions, integer importance, acknowledged/paused transitions and hold reasons are still independent. Parent/child workorders need an explicit mapping. |
| ComponentMaintenanceProjectCoordinate several maintenance partitions for a customer and main shop. | Partial Parent WorkorderMaster; FinancialProjects for commercial cost control only | Workorder headers overlap with project descriptions, responsibility, facilities and dates. | The project aggregates multiple partitions and blocks closure until they close/cancel. FinancialProjects is a budget/cost aggregate, not the operational replacement. Preserve customer ownership and aggregation. |
ComponentMaintenanceTaskGroupGroup reusable component TaskCards by shop and sequence.Source evidenceComponentMaintenanceTaskGroup.cs · ShopMaintenanceModelCreating.cs · MaintenanceTask.cs · TaskCard.cs | Partial MaintenanceTask parent/child hierarchy (existing Dropped review decision) | MaintenanceTasks has a hierarchy; TaskCards also retain component group text and the old group FK. | Despite Dropped in HTML, this class, DbSet, table mapping and TaskCard FK remain. Map group identity/text/facility/order and TaskCard membership before removing it. Template grouping is a different possible design, not an adopted replacement. |
| ComponentMaintenanceTemplateTaskOrdered mandatory/optional TaskCard membership in a component template. | Partial WorkTemplates + TaskCards; WorkTemplateLinks / WorkTemplateItems are possible association replacements | The association already points to shared WorkTemplate and TaskCard records. | The association itself remains mapped. WorkTemplateLink lacks mandatory and sequence fields; WorkTemplateItem points to repository steps rather than directly replacing this TaskCard membership. Preserve revision, ordering and mandatory semantics. |
| ComponentMoclRevisionPublish and retain official/internal maintenance capability list editions. | Dedicated ComponentMoclRevisions; Revision.EntityRevisionStates supplies shared revision infrastructure only | Publication creates internal/official snapshots, supersedes prior editions, hashes content and locks published records. | Generic revisions and workorder revisions do not replace an organization capability publication. Keep the publication aggregate. |
| ComponentMoclRevisionItemFrozen capability lines within a published MOCL edition. | Dedicated ComponentMoclRevisionItems; live ComponentProductionGroupPartSeries is its source | MOCL publication copies capability, part-range/rating and authority approval values into immutable edition items. | Live capability masters cannot reproduce historical edition content or change reports. Keep the snapshots. |
ComponentModificationStatusPersistent engineering modification applicability, due/compliance and component status.Source evidenceComponentModificationStatus.cs · EngineeringOrderCompliance.cs · MaintenanceEventMaster.cs | Partial MaintenanceEventMasters / MaintenanceEventDueLimits + MaintenanceAccomplishments; EngineeringOrderCompliances is related | Shared planning/evidence can represent due work and accomplishment; workorders/steps perform that work. | EngineeringOrderCompliance requires AircraftTailId and does not replace the serialized component register, document status, modification plan or repair/transfer context. Retain the register until component compliance ownership is implemented. |
| ComponentPlanningRecordForecast unassigned component demand and later assign it to maintenance work. | Partial MaintenanceEventMasters + Maintenance.MaintenanceEventDueLimits + WorkorderMaster + ProductionPlanAssignments | Common events already have component/part/serial, due, condition, effort, FIFO and planning fields; shared limits calculate due values. | The old controller still calculates and links its own records. Stock quantity, warranty/capability/installed snapshots, yield, assignment/deassignment and source lineage require reconciliation. Its calculate operation currently updates yield, not the shared due-limit engine. |
| ComponentProductionGroupDefine internal shop capability groups and their validity. | Partial BusinessPartnerCapabilities + ComponentProductionGroups | BusinessPartnerCapability represents shop/part/authority capability; the verification endpoint compares it with production-group parts. | Group identity, group expiry and child qualification/series membership are not replaced by a header group-name string or one partner capability row. |
| ComponentProductionGroupPartAssociate specific/unknown part numbers with capability groups, series and qualifications. | Partial BusinessPartnerCapabilities + PartMaster; existing ComponentProductionGroupParts association | Partner capabilities can identify an approved part and shop. | They do not preserve this group-to-series-to-qualification association, unknown-part handling or project applicability. A Workorder.PartId only identifies the maintenance subject. |
| ComponentProductionGroupPartSeriesGovern part-series capability ranges, maintenance level, CMM revisions and authority grants. | Partial BusinessPartnerCapabilities + PublicationMaster; existing ComponentProductionGroupPartSeries | Partner capabilities overlap with ratings, maintenance level, manual revisions and FAA/EASA acceptance. | Range applicability, series identity, aircraft/model scope, grant mutation history and MOCL linkage remain on this table; approval and CMM update endpoints still use it. |
| ComponentProductionGroupQualificationAssociate planning qualifications and expiry with an internal capability group. | Partial PlanningQualifications + ComponentProductionGroupQualifications | Qualification definitions are already shared. | The group-specific association, qualification-type code and capability expiry remain necessary. Resource assignment consumes requirements; it does not replace this applicability rule. |
| ComponentShopProductionCapacityStaff/skill/shift capacity supply and recurrence. | Shared counterpart ProductionPlanCapacities | Common capacity supports facilities, qualifications, shift/aircraft scope, fractional employees, hours and recurrence. | Map AvailableManHours to ManHours, EmployeeCount to Employees and recurrence/time fields. Redirect capacity summaries/conflicts and preserve Facility versus PhysicalLocation identity. Both old and common model families remain mapped; operational cutover and data migration are not demonstrated by this review. |
| ComponentShopProductionPlanComponent shop schedule header with planning and production baselines. | Shared counterpart ProductionPlans | Common plans support component AssetType, order/facility scope, release, templates and version lineage. | The old controller still owns separate plans and active version pointers. Migrate pointers into common version roles and preserve one logical plan with concurrent planning/production versions. Both old and common model families remain mapped; operational cutover and data migration are not demonstrated by this review. |
| ComponentShopProductionPlanItemScheduled tasks, groups, findings and milestones with progress/layout. | Shared counterpart ProductionPlanElements | Common elements support hierarchy, Workorder/WorkStep/TaskCard links, timing, effort, suspension and milestone/group flags. | Map ComponentWorkpackageEventId to the actual executable WorkStep/order, reconcile ATA text to AtaId, statuses and progress, and redirect booking refresh. Both old and common model families remain mapped; operational cutover and data migration are not demonstrated by this review. |
| ComponentShopProductionPlanLinkPredecessor/successor schedule dependencies and lag. | Shared counterpart ProductionPlanLinks | Common links supply predecessor/successor plus lag and explicit dependency types. | Map legacy semantics to the correct dependency type; redirect links to migrated elements and preserve version membership and cycle rules. Both old and common model families remain mapped; operational cutover and data migration are not demonstrated by this review. |
| ComponentShopProductionPlanTemplateReusable schedule layout, applicability and defaults. | Shared counterpart ProductionPlanTemplates | Common templates include component part/facility/condition applicability, nested groups, snap/layout and activation/archive. | Convert minute/hour offsets and snap strings, resolve facilities, migrate template references and verify apply-template behavior. WorkTemplate is an instruction template, not this schedule template. Both old and common model families remain mapped; operational cutover and data migration are not demonstrated by this review. |
| ComponentShopProductionPlanTemplateItemReusable schedule groups, tasks and milestone layout. | Shared counterpart ProductionPlanElements (ProductionPlanTemplateId) | One common element model serves schedule and template ownership and carries TaskCardId/layout/effort/classification fields. | Map ComponentMaintenanceTaskId to TaskCardId, parent hierarchy and classification fields; preserve task association when applying or saving templates. Both old and common model families remain mapped; operational cutover and data migration are not demonstrated by this review. |
| ComponentShopProductionPlanVersionSimultaneous planning, production and historical schedule versions. | Shared counterpart ProductionPlans (InitialPlanId, VersionNumber, VersionRole, SourceVersionId) | Common plan rows are versions; CopyAsync supports planning/snapshot copies with elements, links and capacities. | No separate common version table is needed. Migrate old version IDs/statuses and active/production pointers; generic entity revision alone is not a schedule-version replacement. Both old and common model families remain mapped; operational cutover and data migration are not demonstrated by this review. |
| ComponentSwapLogRecord a paired removed/installed serialized component swap and technician. | Partial Maintenance.WorkStep component-change entries + RotableLogbookHistories + ConfigurationPositionBookings | Step entries describe component movement and performed actions; the asset logbook stores installation/removal history. | Preserve the paired old/new part and serial identity and technician. A generic movement field does not perform a swap or update both assets/configuration. No complete swap-to-shared workflow replacement was found. |
ComponentTaskFormulaDefine named measurement formulas and repair/calibration reporting flags.Source evidenceComponentTaskFormula.cs · WorkStepMeasurementValidation.cs · MeasurementIdentifier.cs | Dedicated ComponentTaskFormulas consumed by WorkStepMeasurementValidation; MeasurementIdentifier is a definition master | The shared completion validator evaluates the existing ComponentTaskFormula expressions. | The validator reuses this table; it has not replaced formula storage. MeasurementIdentifier has no formula expression/dependency fields. Keep formula definitions or introduce an explicit common formula definition/snapshot. |
| ComponentTaskLinkOrdered task/measurement document, URL or reference links. | Partial Relationships.EntityLinks + Shared.Attachments/AttachmentLinks; external reference metadata still needed | Shared relationships link registered records; attachments link stored documents to any business owner. | EntityLink does not store arbitrary URL/description text. Preserve measurement-level scope, sequence, link category and external target; current TaskCard still owns ComponentTaskLinks. |
| ComponentTaskMeasurementTask-level numeric/text/pass-fail measurement definitions, limits and report flags. | Partial MeasurementIdentifier + Maintenance.WorkStep MeasurementDefinition rows + Maintenance.WorkStepMeasuredResults | Common source validator adapts component definitions to MeasurementIdentifier and stores a definition snapshot with readings. | ComponentTaskMeasurements remains mapped and queried. Move revisioned TaskCard association/local code, signature and report/calibration rules before retiring legacy definitions. This is source-level integration, not verified DB adoption. |
| ComponentTreeLabelBookingBook an assembly tree, calculate completeness and request labels/component release. | Dedicated ComponentTreeLabelBookings; related ConfigurationMaster/Configuration, RotableMaster and release records | The dedicated booking operations apply transactions and recalculate missing LRU/QEC/optional counts. | Configuration describes allowed structure; WorkStep describes performed work. Neither replaces this booking batch and completeness workflow. A release flag also needs integration with authoritative release evidence. |
| ComponentTreeLabelBookingItemAssembly-instance tree with serialized children, expected positions and check state. | Partial RotableMasters + Configuration/ConfigurationMaster/ConfigurationPartNumberAllowances + ComponentWorkpackageNodes | Shared asset/configuration models cover asset identity, functional positions and allowed parts. | Booking snapshot, missing-item classes, parent/child instance positions, sequence and check status still require ownership. ConfigurationPositionBooking is aircraft-tail scoped, so it does not directly replace a component assembly booking. |
| ComponentTreeLabelBookingTransactionInstall/remove/replace/confirm-position transactions within an assembly booking. | Partial Maintenance.WorkStep action evidence + RotableLogbookHistories | Booking operations already write/remove asset logbook history for relevant transactions. | The transaction still carries batch/item links, paired position/part/serial context, labels, special-booking modes and release requests. Shared evidence/logbook entries do not replace the command or its side effects. |
| ComponentWorkpackageDamageIdentify reported component damage, location, raiser and closure. | Partial Maintenance.DefectDamageReports + Maintenance.DefectDamageDetails; WorkStep for rectification | Canonical reporting fields cover damage number/description/type/location and reporting provenance. | DefectDamageScope explicitly retains IsClosed in the legacy workflow. Migrate node ownership, closure and references before retirement; a reporting alias does not replace closure. |
| ComponentWorkpackageEventComponent visit events/tasks with due, planning, execution and assignment context. | Partial MaintenanceEventMasters/MaintenanceEventDueLimits + WorkorderMaster + WorkStep + ProductionPlanElements | Common event/limit models cover planning; WorkStep covers execution; common plan elements cover scheduling. | The component event remains independently mapped and drives legacy auto-generation/progress. Reconcile event classification, node context, sign-off, transfer, staffing and status before choosing one owner for each function. CriticalEvent is a requirement/category lookup, not this event instance. |
| ComponentWorkpackageFindingRecord a finding with rectification, disposition and staff sign-off. | Partial Maintenance.DefectDamageReports/DefectDamageDetails + WorkorderMaster/WorkStep; ProductionFindings also overlaps | Shared reports cover the reported condition; common execution supports actions and findings. | Legacy finding status, signed rectification, event/source-step ownership and release-readiness queries remain. ShopMaintenanceService still blocks release on open component findings. Unify these gates before retirement. |
ComponentWorkpackageLinkHeader document/URL references and technical-query text.Source evidenceComponentWorkpackageLink.cs · ComponentWorkpackageController.cs · EntityLink.cs · Attachment.cs | Partial Relationships.EntityLinks + Shared.Attachments/AttachmentLinks; explicit technical-query/reference records | Shared relationships and attachments cover internal entity edges and files. | The current technical-query endpoint writes subject/details into LinkDescription/LinkTarget. Preserve these text/URL targets and query lifecycle; EntityLink alone cannot store them. |
| ComponentWorkpackageModificationStatusRecord a modification found/performed on a component during this visit. | Partial ComponentModificationStatuses + Maintenance.WorkStep action evidence + MaintenanceAccomplishments | The persistent register tracks component modification status; execution/evidence records can record performed work. | Visit/node scope, Found versus Performed action, type, reference/document and modification date must remain linked. Persistent compliance and a visit snapshot are different records until explicit lineage is added. |
ComponentWorkpackageNodeVisit-specific physical component hierarchy, quantities, conditions and progress.Source evidenceComponentWorkpackageNode.cs · ShopMaintenanceService.cs · ConfigurationDefinitionModels.cs | Partial RotableMasters + Configuration/ConfigurationMaster + WorkorderMaster | Asset masters and configurations cover serialized identity and permitted structure; workorders cover maintenance ownership. | Retain the visit snapshot/tree, node-specific release quantity, condition/warranty/counters and routing. A parent/child workorder hierarchy is a work breakdown and does not automatically reproduce the physical assembly tree. |
| ComponentWorkpackageRevisionVisit revision history, reason/remarks and work-template synchronization state. | Partial Revision.EntityRevisionStates + Audit history + WorkTemplateRevisions | Common revision state supplies current issue/revision identity, reason and lineage; shared audit supplies mutation provenance. | EntityRevisionStates is unique per entity and represents current state. Preserve multiple legacy revision rows, active history and IsWorkTemplateSynchronized; template revision alone does not record visit adoption. |
Basis: model definitions, EF configuration, controllers/services and existing review metadata. Existing index field counts are historical catalog values. This review does not certify the currently deployed database, data migration or production behavior.