Skip to content
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

feat: change task type when element template is applied #648

Merged
merged 9 commits into from
Apr 4, 2022

Conversation

marstamm
Copy link
Contributor

@marstamm marstamm commented Mar 31, 2022

Try it out with

npx @bpmn-io/sr bpmn-io/bpmn-js-properties-panel#572-element-template-change-task-type -c 'npm run start:cloud-templates'

Recording 2022-03-31 at 11 10 01

This PR allows you to define a elementType that will be enforced when a template is applied

  • We use the bpmn MetaModel to define what can be changed
  • Only same base types can be used for replacing (Task, Event, Gateway). Other Combinations result in invalid templates
  • Works for cloud and platform

closes #572
closes #642

@marstamm marstamm requested review from pinussilvestrus and a team March 31, 2022 09:21
@marstamm marstamm self-assigned this Mar 31, 2022
@marstamm marstamm requested review from MaxTru and removed request for a team March 31, 2022 09:21
@bpmn-io-tasks bpmn-io-tasks bot added the needs review Review pending label Mar 31, 2022
@pinussilvestrus
Copy link
Contributor

/cc @nikku

Copy link
Contributor

@pinussilvestrus pinussilvestrus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From quick testing I can say it works 👏

Implementation wise we should consider some things before we merge it. 👍

package.json Outdated Show resolved Hide resolved
src/provider/cloud-element-templates/Validator.js Outdated Show resolved Hide resolved
src/provider/cloud-element-templates/Validator.js Outdated Show resolved Hide resolved
src/provider/element-templates/Validator.js Outdated Show resolved Hide resolved
@bpmn-io-tasks bpmn-io-tasks bot added in progress Currently worked on and removed needs review Review pending labels Mar 31, 2022
@nikku
Copy link
Member

nikku commented Mar 31, 2022

@marstamm I could only have a quick look on this today. If a detailed look is needed from my end I can see what I can do tomorrow or on Monday.

@marstamm
Copy link
Contributor Author

@nikku , I will tackle the "return new element" topic tomorrow, so nothing urgent. @pinussilvestrus already gave some great suggestions on the code, but would be great to get some feedback if it is the correct behavior for connectors as well.

@nikku
Copy link
Member

nikku commented Mar 31, 2022

Added a few more comments, especially around the change command.

TLDR: Let us work with the newly introduced ElementTemplate#applyTemplate API for "applying a template" exclusively; let us encapsulate the "element can change" logic within that API call.

@nikku
Copy link
Member

nikku commented Mar 31, 2022

Will test drive this against connectors as soon as I can.

@marstamm
Copy link
Contributor Author

marstamm commented Apr 1, 2022

I added the requested changes in separate commits to help with reviewing the changes. I will squash them before merging. Ready for another round of reviews 🏇

(Please wait for Nico to confirm the behavior in Connectors land before approving)

@marstamm marstamm requested a review from pinussilvestrus April 1, 2022 13:03
package.json Outdated Show resolved Hide resolved
@marstamm marstamm force-pushed the 572-element-template-change-task-type branch from 5434384 to 1577ab4 Compare April 4, 2022 10:19
@marstamm
Copy link
Contributor Author

marstamm commented Apr 4, 2022

Added last review hints and squashed all commits

@nikku
Copy link
Member

nikku commented Apr 4, 2022

From what I found during initial testing, this works like a charm!

We are aware of bpmn-io/bpmn-js-connectors-extension#32 as a limitation, but I guess our users will verify how crucial of a limitation that is, post April 12th 😉.

@nikku
Copy link
Member

nikku commented Apr 4, 2022

I found one bug, not related to this PR, but to the overall "check if properties are still valid during replace" interaction:

  • Given I have a template that defines a task header <a>
  • If I change to another template that does not define task headers
  • Then the task header <a> binding is not cleaned up

I believe this is due to our C7 legacy of "only touching what has been defined"; it does not seem to be the appropriate behavior for C8 anymore.


Created a bug for this (#653).

package.json Outdated Show resolved Hide resolved
templates.addAll(templateDescriptor);

// then
expect(errors(templates)).to.contain('template(id: <example.com.TaskToGateway>, name: <Element Type (Task -> Gateway)>): can not morph <bpmn:ServiceTask> into <bpmn:ExclusiveGateway>');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the reason for this limitations?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We want to prevent the changing to broken types, like Task -> Process or Task -> SequenceFlow. As the simplest approach, we decided to only allow Task -> Task, Gateway -> Gateway and Event -> Event

cf. camunda/element-templates-json-schema#48 (comment)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, one way to approach this would also be "allow users to do what they want" (and see how the editing experience blows up in the process) :).

But I see how we rather want to be safe.

If we got that route though, why do we choose bpmn:Task and not bpmn:Activity as the base for all "task nodes".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we choose bpmn:Task and not bpmn:Activity

Good point, I see no reason for it. I'll change it 👍

Copy link
Member

@nikku nikku left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code-wise I have two concerns (but just comments at this point):

Is the direct bpmn-moddle dependency really required? What do we achieve with it (in terms of features / safeguarding our users) that we don't achive by other means?

What is, in two simple lines our rules for "appliesTo" / "elementType" validation?

I'm missing a bunch of comments (examples) in the test suite / source code which makes our logic there hard to follow.

@marstamm
Copy link
Contributor Author

marstamm commented Apr 4, 2022

What is, in two simple lines our rules for "appliesTo" / "elementType" validation?

We validate that:

  • The Element Template also applies to the elementType Target
  • The appliesTo and elementType have compatible classes (eg. no Task -> SequenceFlow allowed)

What do we achieve with it (in terms of features / safeguarding our users) that we don't achive by other means?

We need it to check the above Assumptions. E.g.,

appliesTo: ['bpmn:Task']
elementType: {
  value: 'bpmn:ServiceTask'
}

is valid, but requires the meta-model to validate that the Service Task is a subClass of Task.

@nikku
Copy link
Member

nikku commented Apr 4, 2022

Cf. #648 (comment).

Maybe we can re-use the existing moddle instance?

@marstamm marstamm force-pushed the 572-element-template-change-task-type branch from 1577ab4 to 628a98a Compare April 4, 2022 14:24
export default function validate(descriptors) {
return new Validator().addAll(descriptors).getErrors();
export default function validate(descriptors, moddle) {
return new Validator(moddle).addAll(descriptors).getErrors();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really happy with this one, but we can't move the validation to ElementTemplates because that would cause a circular dependency in the TemplateFactory

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thing we're fine with this.

Moddle is the meta-model we rely on. If we start to validate type hierarchies (which you decided to do) there is no other way to add this.

@marstamm marstamm force-pushed the 572-element-template-change-task-type branch from 628a98a to b378bd2 Compare April 4, 2022 14:29
Copy link
Member

@nikku nikku left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added 7eb303b on top. Looks good to me.

@fake-join fake-join bot merged commit eaa7436 into master Apr 4, 2022
@fake-join fake-join bot deleted the 572-element-template-change-task-type branch April 4, 2022 18:37
@bpmn-io-tasks bpmn-io-tasks bot removed the in progress Currently worked on label Apr 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants