-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add link-event
rule
#128
Add link-event
rule
#128
Conversation
The existing rule in |
The question is: Do we direly need this? What is the loss if we don't focus the name property here? One option is to remove that "additional selection behavior". The other option could be: Inject these additional properties after the fact, i.e. as part of a linter post-validation hook that bpmnlint-plugin-camunda-compat hooks into. Either way such a rule belongs to the core. We can on the Camunda side of things decide if we use it or not. |
We already attach meta data (property paths) in some places, i.e. here. |
Well, that would save us a lot of hassle but we've decided to focus the corresponding properties panel input when clicking on an error. However, we need to rethink the current implementation due to camunda/camunda-modeler#3896 anyway. We will probably have to go with a solution that relies on |
Verifies correct usage of link events: * name must be specified * only a single pair of link {throw/catch} (no fork/join) * no linking across scopes Related to camunda/camunda-modeler#3532
How is linking across scopes validated? It's not explicitly validated, right? We simply validate that within a scope there's a pair of catch and throw events and if that's not the case it could be due to linking across scopes. |
We could simply do it and see when someone notices, especially as the resolution for links is not to "simply fix the name". Misuse (cf. this PR) can stem from many things, including having the link target in a wrong scope. This is not fixed by correcting the name, but moving the element (or deleting it all together). |
We are not here to "explain linking", but to identify errors (and layout the basic rules). Documentation tries to pickup the user, i.e. clearly tell what wrong usage exists: https://github.com/bpmn-io/bpmnlint/pull/128/files#diff-1c0cd3d147700fbecbfc2f14e57a1438fd5f920c628975153a9b6e9ab29629b0. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job! 👷🏻♂️
Enforces good practices for using link events, as laid out in the BPMN specification:
Cf. 0b96cda#diff-53281e111f51ee34e0d60298dd6d4d1c814830877ee9c83edc81b973ec8e1d8bR25 for proposed error messages.
Detected Correct Usage
Detected Incorrect Usage