This issue is a regression, been caused by KOGITO-7717

Background

The model classes ( see at [1] ) used in SWF domain are actually NOT declaring all fields, compared with the specification. The classes that are representing the models, are just declaring the fields which we have some interest in, for further usage in the editor code. This means that classes are not populated with fields out from our interest.

The parsing is also considering this, as the parsed objects (from the source JSON), will preserve other fields , rather than the declared ones by the object's class.

Also once marshalling from the objects to an stream, the resulting stream will contain all fields, as from the user's source input, either if they're declared in the class model or they're not.

This way our models has some reduced scope, but obects at runtime will anyway preserve all fields being parsed from a json type.

[1] https://github.com/kiegroup/kie-tools/tree/main/packages/serverless-workflow-diagram-editor/sw-editor/sw-editor-api/src/main/java/org/kie/workbench/common/stunner/sw/definition

Issue

Acutal parsers (since KOGITO-7717 being merged), are only serializing the declared fields in the class. Although our models are not declaring all possible fields, compared from the spec, so this results on loosing information once serializing the workflow.

How to reproduce

Just try to use an input JSON that contians some attribute/field not being declared in our model classes, open and then save. The resulting JSON file will not contain that field, but it should, as result after saving must be the same one once opeining the wf.

Comments

I understand a possible solution could be fill the model with all missing fields, but on the other hand, we're trying to preserve the models as reduced scope as possible, so we are just declaring fields that are from our interest. 

Also another downsides are if users have custom parts in the input source (JSON), that are not even matching the spec, they'll be lost just after updating.

So I think we have to analyze and discuss some potential solution for this behavior in the parsers. Maybe can we just some custom mapper?