Closed FO-e-X closed 4 years ago
Please link to the resources you're quoting and add screenshots that make your case. It is otherwise hard to follow your line of thought.
Even better, create a small screencast that records a broken interaction.
Sorry, I missed, that the issue isn't placed at the folder I opened it, but it placed at the project root... I named the plugin already, here is the link https://github.com/camunda/camunda-modeler-plugins/tree/master/bpmn-js-plugin-embedded-comments
I add some screenshots, because a screencast is a bit difficult here. Also I builded a little dummy process. The scenarios I will divide...
scenario 1, first comments
adding some comments...
element documentation
XML (btw: modeler 3.6.0 and plugin embedded comments master from last week -> saving comments is only possilbe when modifying the model... ah, sorry, I forgot: no btw ;) )
`
scenario 2, first documentation
adding some documentation
Now adding some comments
XML (again, comment changes are only saved after editing something others in the bpmn)
`
I hope it's now more clear what the strange behaviors are. Both ways run in into other mistakes, both are a combination of unwanted cross-editing from Camunda Modeler an embedded-comments-plugin. I think, the plugin itself can't fix this problem without some changes in the Modeler. The Modeler should respect special documentation elements. Maybe a fix in the Modeler only will fix all these problems. Only show simple documentation entries and ignore special documentation elements as well as leaving them untouched. It's a bit like scenario 2, but without deleting all documentation elements when removing the simple documentation :)
Regards, Frank
Thanks for providing additional details.
From what I can see this is an issue with the fact that the Camunda Modeler drops the textFormat
attribute, while it
a) Should ignore the documentation, unknown to her entirely or
b) keep the textFormat
attribute
I've opened https://github.com/camunda/camunda-modeler/issues/1682 to track this as a bug. Please cross read it to see if it captures your issue.
Closing this issue, as it is really a modeler bug that needs to be fixed.
Hi,
there is a strange behavior in combination with embedded comments and the documentation element. As I can see, the comments are stored in bpmn:documentation-elements with the attribute textFormat="text/x-comments". OK, its fine for me. But now I found a difference between first adding comments and then add my own documentation and first adding my own documentation and then add comments.
scenario 1, first comments: An element with textFormat="text/x-comments" is added and shown as documentation in properties panel. When I add my own documentation the attribute textFormat is lost and all comments are part of the normal documentation element. But, now it get really strange, its removed in the XML but the plugin seems to use the known comments only. If I now add a new comment, all other comments are gone, only the new one(s) are shown as comments. The former comments are now plain documentation too. I think this isn't a correct behavior.
scenario 2, first documentation: An element without textFormat appears in the XML. When adding comment(s) now, another element with textFormat is added after the first plain documentation element. The plugin knows to use only the comments. The properties panel documentation element only shows my own documentation. And even the property info plugin knows, that only the first plain documentation element is to use. This sounds really like the desired behavior. Now try to delete the plain comment... The modeller removes all documentation elements for the BPMN-element, including the comments. But some caches do the magic, the plugin continues showing the comments. Unfortunately the cached comments do not survive closing and reopening the BPMN-model.
My suggestion: When the first comment is added, check for other documentation elements and add the one with textFormat at the end. If no other documentation is availabe, add an empty plain documentation element first. But at the other side, the modeler itself need a fix. When deleting the plain documentation, its not a good idea to delete all documentation elements. Maybe an empty element must remain if other documentation elements are available at the BPMN-element.
Sorry for this long text. But I hope it can help to understand the problem better :)
Regards Frank