Skip to content

Handle multiple levels of catalog element representation - #1689

Open
iTerminate wants to merge 14 commits into
masterfrom
issue-1688
Open

iTerminate wants to merge 14 commits into
masterfrom
issue-1688

Conversation

@iTerminate

Copy link
Copy Markdown
Contributor

…. Closes #1688

@iTerminate

Copy link
Copy Markdown
Contributor Author

I investigated the implications of removing the one-level representation constraint. Multilevel resolution appears structurally supported, but this change exposes several integrity risks that should be addressed or explicitly tested before merge:

  • A represented parent can currently be unlinked while it still has represented children. Clearing the parent reference has no descendant validation, so those children can retain references into an assembly the parent no longer represents.
  • Catalog element removal/replacement constraints do not consider representsItemElementList. Also, represents_item_element_id has no database foreign key, so deleting a represented catalog element may leave dangling references.
  • /PromoteMachineElement accepts an independently supplied element and only checks that it belongs to some catalog/inventory item. It does not verify membership in the requested parent's assigned assembly or prevent duplicate sibling representation.
  • No circular-reference validation was found. Multilevel representation may expose catalog assembly cycles through hierarchy traversal.
  • Template propagation and catalog assembly swaps need explicit three-level tests.

At minimum, I recommend blocking unlink of a represented node with represented children, validating REST promotion against the parent's available elements, and adding tests for three-level hierarchies with/without templates, middle-node unlink, catalog element removal/replacement, assembly swap, and circular references.

 - Catalog promotion
     - Old: Any catalog element could be promoted, even if the parent
machine was not assigned its assembly.
     - New: The element must belong to the parent machine’s assigned
assembly.

 - Inventory promotion
     - Old: Any inventory element could be promoted and normalized to
its catalog element.
     - New: It must belong to the parent’s assigned inventory/catalog
assembly before normalization and promotion.

 - Unsupported-domain promotion
     - Old: Rejected with a domain-specific error.
     - New: Still rejected, but currently fails the parent-assembly
availability check first; validation should be reordered to preserve the
old error.

 - Nested representation
     - Old: Always rejected when the parent machine already represented
an element.
     - New: Allowed when the child represents an element from the
parent’s effective represented assembly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support multiple levels of machine design element representation.

1 participant