Association deletion in CC revision

https://github.com/OAGi/Score/issues/486

1. Allow deleting the association(s) from a revised ACC.

#1 - Remove ASCC/BCC record from DB.
- Execute the same logic we are currently taking for rev=1. Unlike ACC/ASCCP/BCCP, ASCC/BCC will be permanently removed from DB.
- A history of this action is stored in Log table.

Pros:

• easier to implement

Cons:

• Harder to provide undo.

• Not possible to document about the deletion.

#2 - Mark as a ‘Deleted’ state.
- Do we need to keep properties such as ‘guid’ or ‘definition’ for the association deleted by the actions? What if the user often takes ‘Add/Delete’ actions for the same association?

1- How to show the deleted association.

Pros:

• One can easily see deleted association in the past. (but it means, we need to provide Hide Deleted button).

• Can restore the deleted association in the past. Basically undo.

• It would allow user to document why it is deleted or refactored.

Cons:

• more to implement

• Should we preserve the ‘Deleted’ CCs in the new release?

  • Yes, preserve only deleted associations as part of the release.

1. Questions
   - No need to worry about backward-compatibility? What if the developer misses the insert?
   - If there are BIE references (for End-user CCs and Extensions), block the deletion.
   - Uplift

   1. for {a.} logic should be changed. b/c we are using GUID for matching key. but we cannot keep the removed record's GUID.

   2. for {b.} deleted state association is not available in BIE.

2. ‘Move to’ feature (One of refactor features).

   1. to upper-level ( O )
      e.g.
      Production Order Line Base. Details - Lv. 4
      - Status Line Base. Details (*) - Lv. 3
      - Line Base. Details (o) - Lv. 2
      - Line Identification Base. Details (o) - Lv. 1

   2. to lower-level ( X )
      e.g.
      Production Order Line Base. Details (o)
      - Status Line Base. Details (*)
      - Line Base. Details
      - Line Identification Base. Details

Maintenance Order Line Base. Details (o)
- Status Line Base. Details (*)
- Maintenance Line Base. Details
- Line Identification Base. Details

- If there are multiple ACCs that are based on the same target ACC, it cannot be available.
e.g. Maintenance Order Line Base / Shipment Request Order Line Base / Shop Floor Control Base Line Base ...

1. Are we allow the move to only {a.} ? if there is only one {b.}, should we allow it?

Yes. It is fine to support only refactoring up first. Supporting refactoring down is more involved. The application needs to find all ACC hierarchies that include the refactored down ACC and ask the user where to refactor the association to in these other hierarchies.

Refactor up also needs to check for other deriving ACCs that need to be refactored as well due to potential for duplicate properties. This is also related to adding a property that may cause duplications in the derived ACC. This checking process can take very long, e.g., when adding or refactoring an association into the Identification component. Checking for duplication associations in the derivation hierarchies shouldn’t be done every time a property is added. It is ok to do this for refactoring b/c refactoring doesn’t happen often and there is also potential automation to refactor those affected ACCs. Checking for duplication properties (as a result of property additions) should be done at the release validation.

Refactoring an association consists of deleting and adding the association. At this time, we can implement association deletion but do not expose it. We only expose refactoring to ensure the backward compatible release. I.e., we also keep the message that for now Score only supports backward compatible releases.

Refactor up => Move to the Base ACC

Refactor down => Move to derived ACCs

On 9/20/2021, we park the association deletion and started a new page on Refactoring Association.