search

OAGi / Score

Score
MIT License
9 stars 6 forks source link

Reducing the amount of steps need to edit a nested reused bie #1604

Open smorgan19 opened 9 months ago

smorgan19 commented 9 months ago

When a user needs to update a nested reused bie, it can become cumbersome to move all the upper level reused bie to WIP. For example with the path NofityBOM/BOM/BOMOption/BOMItemData/Item/Party/SecurityClassification/Extension, if you need to enable the measure attribute under extension. You would need to move 8 bies from QA into WIP to make one edit and then move all of them back to QA. This can become more complex if say the security classification is used in another BIE. Is it possible to reduce the amount of bies that need to be opened/states changed or steps required to edit a heavily nested bie?

hakjuoh commented 9 months ago

@smorgan19 @joshklm @kbserm @elena-jelisic I applied the cascade state update to (nested) reused BIEs only if the ownership among BIEs is the same. Here's an example case:

Screenshot 2024-02-20 at 9 37 09 AM

If the user updates the 'Notify BOM' BIE state to 'QA', all reused BIEs' states will be 'QA' as well.

Screenshot 2024-02-20 at 9 37 34 AM

If there are reused BIEs with different ownership, they will be ignored. Please let me know what you think. @elena-jelisic I uploaded a new PR for this issue: https://github.com/OAGi/Score/pull/1606

hakjuoh commented 9 months ago

@kbserm @joshklm I'm writing the following notes to document the matters discussed during the meeting.

Case BIE (state/ownership) Reused BIE (state/ownership) Reused BIE within the reused BIE (state/ownership)
Case 1 Notify BOM (WIP/ serm) BOM (WIP/ serm) BOM Option (WIP/ serm)
Case 2 Notify BOM (WIP/ serm) BOM (WIP/ serm) BOM Option (QA/ serm)
Case 3 Notify BOM (WIP/ serm) BOM (QA/ serm) BOM Option (QA/ serm)

In Case 1, user1 must first update 'BOM Option' to QA in order to update 'BOM' to QA (Case 2). After that, 'Notify BOM` can be updated to QA (Case 3). Since all BIEs are owned by user1, there is no difficulty in propagating status change requests from the upper BIE (Notify BOM) to the lower ones (BOM and BOM Option).

Case BIE (state/ownership) Reused BIE (state/ownership) Reused BIE within the reused BIE (state/ownership)
Case 4 Notify BOM (WIP/ serm) BOM (WIP/ hakju) BOM Option (WIP/ elena)
Case 5 Notify BOM (WIP/ serm) BOM (WIP/ hakju) BOM Option (Production/ elena)
Case 6 Notify BOM (Production/ serm) BOM (Production/ hakju) BOM Option (Production/ elena)

However, in Case 4, where ownership of each BIE belongs to different users, status change requests cannot be forwarded (Problem 1). Moreover, as @joshklm mentioned in the meeting, in situations like Case 5 or 6 where there is a need to update the BOM Option, it's necessary to first copy 'BOM Option' and then reuse the newly created 'BOM Option' (ver. 2) with the applied changes. Specifically, in situations like Case 6 where all BIEs are already in Production status, despite the fact that changes are only needed in the BOM Option, it is necessary to copy all BIEs (Problem 2).

joshklm commented 8 months ago

@hakjuoh Thanks for the summary with tables! We will outline our resolutions/suggestions and post it here soon.