You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DISCLAIMER: this issue describes path computation for a single instance/case only. So the implementation will go to the CasePathResolver class as it differs from PathResolver which is a generic implementation that both deals with single instance or all instances of a process.
Is your feature request related to a problem? Please describe
In #12, we try to detect start/end events.
We could evaluate if we can do the same with BPMN links, based on the completed successors and predecessors or any other information that could be relevant in the model.
This should be enable only when an option is set, see #23. For example, an option named inferLinkEvents.
As a first step, the processing is closed to the one done for start/end event in #12
Find catch and throw link events that can be deduced from completed elements.
This is something closed to inferring pending elements
a throw link event directly following a completed element should be computed as completed
a catch link event directly before a completed element should be computed as completed
given the computed catch and throw link events, find their related source/target using the new bpmn-visualization feature
consider them as completed
Interactions with #145: do the 2nd step before inferring the pending element.
This use case requires dedicated tests. If this issue is implemented prior to #145, create a dedicated issue to manage this specific use case. Otherwise, implement it as part of this issue.
Question
do we split the implementation into several steps, to move quickly and iteratively?
list more precise use cases in the "solution"
The text was updated successfully, but these errors were encountered:
DISCLAIMER: this issue describes path computation for a single instance/case only. So the implementation will go to the
CasePathResolver
class as it differs fromPathResolver
which is a generic implementation that both deals with single instance or all instances of a process.Is your feature request related to a problem? Please describe
In #12, we try to detect start/end events.
We could evaluate if we can do the same with BPMN links, based on the completed successors and predecessors or any other information that could be relevant in the model.
Having process-analytics/bpmn-visualization-js#2855 may help.
Describe the solution you'd like
This should be enable only when an option is set, see #23. For example, an option named
inferLinkEvents
.As a first step, the processing is closed to the one done for start/end event in #12
Find catch and throw link events that can be deduced from completed elements.
This is something closed to inferring pending elements
As a second step, we can use process-analytics/bpmn-visualization-js#2855 to infer more link events
bpmn-visualization
featureInteractions with #145: do the 2nd step before inferring the pending element.
This use case requires dedicated tests. If this issue is implemented prior to #145, create a dedicated issue to manage this specific use case. Otherwise, implement it as part of this issue.
Question
The text was updated successfully, but these errors were encountered: