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

Message details are not kept, when replacing event type #4863

Open
2 tasks
nikku opened this issue Feb 27, 2025 · 3 comments
Open
2 tasks

Message details are not kept, when replacing event type #4863

nikku opened this issue Feb 27, 2025 · 3 comments
Assignees
Labels
bug Something isn't working modeling ready Ready to be worked on ux

Comments

@nikku
Copy link
Member

nikku commented Feb 27, 2025

Describe the bug

Via #4523 we allowed replacing of typed events with their start*, intermediate* and end* variants. The purpose was two simplify our users lives. Testing the solution I found that we did not go the full length to support our users: If I have a message already configured, I'd expect that message to stay as I replace from message catch (with message A) to message start (with message A):

Image

Steps to reproduce

  1. Model message start, attach a message
  2. Replace with message catch
  3. See no message is attached anymore

(Same can be reproduced in different directions of replacement).

Expected behavior

  • Replacing between catch* versions should keep configured details, where still valid (i.e. correlation key not supported for message start)
  • Replace between throw* versions should keep configured details

Environment

  • OS: Linux (Ubuntu)
  • Camunda Modeler Version: v5.33.0-rc.1
  • Execution Platform: any
  • Installed plug-ins: None

Additional context

Found in the context of #4825.

@nikku nikku added the bug Something isn't working label Feb 27, 2025
@barmac
Copy link
Collaborator

barmac commented Feb 28, 2025

This is a bummer. I did not expect this to happen when implementing the bpmn-js part :/

@barmac barmac added ux modeling ready Ready to be worked on labels Feb 28, 2025
@philippfromme
Copy link
Contributor

philippfromme commented Mar 11, 2025

This also applies to signal references.

@nikku
Copy link
Member Author

nikku commented Mar 11, 2025

@philippfromme Already captured this in the expected behavior:

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working modeling ready Ready to be worked on ux
Projects
None yet
Development

No branches or pull requests

4 participants