Message-ID: <1270014119.1447.1369222854529.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1446_2141809419.1369222854528" ------=_Part_1446_2141809419.1369222854528 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Noticed behavior: After m= aking manual changes to the BPMN 2.0 xml file in the editor, some of those = changes are lost upon save of the diagram.
Workaround: Only use constructs supported by= the diagram view when editing the BPMN directly
Although the behavior may be confusing and at times inconve= nient, this is not a bug, but a feature. You can edit in e= ither the diagram or the XML view, but in both views your are bound by the = functionality we actually support. The essence of the way this wor= ks is that changes made in either view are synchronized to the other view a= nd must therefore be supported by both. Any change to the diagram will rege= nerate the BPMN for all constructs supported.=C2=A0
Obviously, you ca= n use constructs in the BPMN XML than we don't support (and may or may not = be supported in Activiti's engine), but we will not be able to process them= and will therefore drop them upon regeneration from the diagram to BPMN.= p>
The easiest rule of thumb is this: if you can't do it in the process d= iagram, then you can't do it in the BPMN either, even if Activiti engine su= pports it.
If you find a construct you can edit in the proce= ss diagram, but doesn't get synced to the BPMN, then that's a bug. Please r= eport a case like this to us, by filing a Jira issue=C2= =A0for the Designer component and we will look into it. Regenerating the BP= MN for the constructs supported and dropping non-supported output is, howev= er, a feature.------=_Part_1446_2141809419.1369222854528--