Data Object Reference Name - automatically changed

[calexh-sar]

Data Object Reference Name must not be automatically changed if different Data Object is chosen.

Overview

After reviewing the issues page with this discussion, I've listed below some errors/bugs I've found as well as an approach I suggest for good user experience and technical robustness.

Bugs Found

These errors can have an impact on the engine's processing level.

---

Plan of implementation

• [ ] Decoupling Data Reference Name from Data Object ID : prevent automatic updates that can confuse end-users.
  • On Change Data Object ID
  • On Change Data Object Reference (Dropdown)
• [ ] Fixing bugs mentioned above and any new ones to avoid redundancy in the level of XML (engine impacts).
• [ ] (Optional) We can enhance the user interface by adding color attributes or icons or legends so the user can see all the data reference objects that linked to the same data object without going through the properties panel.
• [ ] Implement Test Cases

---

Estimation

The estimation for this task isn't exactly straightforward because there's always a chance of encountering some unexpected errors along the way. However, if we set aside the OPTIONAL UI color feature, my initial estimate would be around 8 to 10 hours to complete the work.

[calexh-sar]

Screen recording by Sasha:

https://github.com/sartography/spiff-arena/assets/54854669/23b72b89-4748-4cff-8c30-5f9f6b85e5df

[calexh-sar]

And from Madhurya in Notion ticket: As per Sasha’s video it seems there are 2 issues around this.

1. When you change the name of the Data Object in the model it changes the name of the data reference
2. When you change the chosen Data Object of a Data reference, it changes the name of the data reference

[danfunk]

The Data Reference is a reference to the Data Object. Decoupling these two and allowing the data object to change names without updating the data reference is a larger bug than not doing it. Daniel Lubke mentioned that we might do something like adding an editable parenthetical to the data reference display, so that it would look like "Countries (complete)" and you could edit the parenthetical to denote state changes to the data object and these could be changed per data reference.

[danfunk]

Sasha writes: The visual thing should make sense for end-users, while the Data Object id should be unique and follow a certain structure. The example would be: Data Object id = Request_gs1 The visual representation across the process model can be: “Request submitted”, “Request reviewed”, “Request approved”, etc. So from the architectural pov, it’s still the same Data Object, but it’s just getting updated over the process. But visually, the user will see that the object is getting updated with statuses.

[calexh-sar]

@sashayar13 and @harmeet-status we have hired a contractor who has extensive BPMN.IO experience and is available to work on this issue now. Would you like for us to pull it into the current sprint?

[sashayar13]

@calexh-sar from my side, this ticket is leaning towards Medium-Low criticality, and if there are other critical tickets in the sprint, they should be picked up first @harmeet-status

[calexh-sar]

@sashayar13 I understand the lower criticality of this ticket and I probably didn't make myself clear on @theaubmov availability. We hired him as a contractor to exclusively work on BPMN.IO tickets since our developers were either not as efficient working in that code base periodically or had more critical work to do. So having him to this work now would not affect the work getting done in a sprint by the rest of the team.

[harmeet-status]

Should we need reference to the old Notion ticket, it is here: https://www.notion.so/Data-Object-Reference-Name-automatically-changed-06cd18c34ab94d779297f6120c1a99b5

[theaubmov]

A new PR has been raised; changes are pushed to the branch 'feature/dataObject-naming-with-dataState'.

For more context:

Data object references have been enhanced with a new property called 'dataState'.

DataState, as a part of the official BPMN standard, is useful in workflows where multiple data object references with the same source (dataObject) are used. It provides an additional label to distinguish and offer more context about the differences between these data object references.

Screenshots below explain the new approach.