>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3304586. --> Reported by: [jurgenhaas](https://www.drupal.org/user/168924) >>> <h2>0&#65039;&#8419; Who is here today? Comment in the thread below to introduce yourself! We&rsquo;ll keep the meeting open for 24 hours to allow for all timezones.</h2> <table> <tr> <td>jurgenhaas</td> <td>J&uuml;rgen from Germany, maintainer of ECA and a couple of other modules</td> </tr> <tr> <td>mxh</td> <td>Max from Offenburg :wave:</td> </tr> <tr> <td>rkoller</td> <td>:wave: ralf from n&uuml;rnberg</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Here from St Charles IL, far western burbs of Chicago... Thanks for the heads up @rkoller</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Inviting @goldin</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>and @Adrianm6254</td> </tr> </table> <h2>1&#65039;&#8419; Do you have any topics to propose for the meeting today? Post in this thread and we&rsquo;ll open threads for them as appropriate. Or you can post them directly in the channel with the next number as an icon. That topic will then turn into a thread for the comments.</h2> <table> </table> <h2>2&#65039;&#8419; Drupal 10 compatibility robot issues</h2> <table> <tr> <td>jurgenhaas</td> <td>Example: <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/eca/-/work_items/3304015" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/eca/-/work_items/3304015</a></span> - we should review and commit proposed patches by the bot and then set the status of the issue to active again. That way, other maintainers know that it's done and doesn't require another review, and the bot knows that it should come along and propose further patches</td> </tr> <tr> <td>mxh</td> <td>The "active" state may lead to confusion for other people, as seen on the D10 compatibility day, but there's no other way to keep the bot involved. Therefore yes, we then just leave it "active" until the bot provides a patch that's worth a look. I don't know at all why the bot claims that the project is not D10 ready yet, it just says that it's not compatible. But looks like it complains on most other projects too that are already working with D10.</td> </tr> <tr> <td>jurgenhaas</td> <td>There has been another heads-up about issue status last night, see <a href="https://drupal.slack.com/archives/C014CT1CN1M/p1660690121157949">https://drupal.slack.com/archives/C014CT1CN1M/p1660690121157949</a></td> </tr> <h2>3&#65039;&#8419; What's up with modellers?</h2> <table> </table> <h2>3&#65039;&#8419;.1&#65039;&#8419; bpmn_io is not accessible</h2> <table> <tr> <td>jurgenhaas</td> <td>Do we want to ping the upstream bpmn.io community about this and see what they're up to?</td> </tr> <tr> <td>rkoller</td> <td>you mean accessibility issue with bpmn_io in general? then yes. those issues should be fixed upstream. but there is one foundational problem - it is difficult to present a visual interface like bpmn_io to a screen reader user that it is operateable for the person. i&rsquo;ve asked mark weiler here on the drupal slack a few days ago and he forwarded the question over to the a11y slack: <a href="https://web-a11y.slack.com/archives/C08J06DKK/p1659960517465919">https://web-a11y.slack.com/archives/C08J06DKK/p1659960517465919</a> but it is an ongoing discussion there and definitely a none trivial problem. the rest of the issue are easier to tackle but as i said best to fix report and fix upstream.</td> </tr> <tr> <td>jurgenhaas</td> <td>That's interesting, haven't thought about those challenges. But that's understandable. Do you know if bpmn.io is aware of this "issue" in general?</td> </tr> <tr> <td>rkoller</td> <td>not sure. i will search their issue queues on the weekend.</td> </tr> <tr> <td>rkoller</td> <td>but there is there is the question if the effort should even be tried taking into consideration that eca_cm exists now. but then there is the question where to draw the line for bpmn_io and how much a11y issue should be implemented and suggested for them. would save a lot of effort to focus with the modellers on different groups. but that is exclusive. but an interesting point to discuss. could bring that up to that drupal a11y channel and ask over there what the best approach would be</td> </tr> <tr> <td>jurgenhaas</td> <td>That's true. On the other hand, if we provide support with e.g. sample models, do we have to distinguish between user groups whether we provide a sample solution in either of the modellers? I can see that growing over our head quickly. Unless we could convert models between the modellers. @mxh converting a bpmn_io model to eca_cm should be easy, right?</td> </tr> <tr> <td>mxh</td> <td>I'd estimate that the core modeller is not a real replacement of what you can do with the BPMNio modeller, since a BPMN diagram effectively helps understanding the modelled workflow. The main goal of the core modeller is to provide a minimalist UI directly on top of ECA's configuration structure. That structure however already showed its drawbacks for understanding the execution chain. I also don't really plan to make the core modeller "better" in that regard, as it's already fulfilling its purpose.</td> </tr> <tr> <td>mxh</td> <td>At least it helps a11y in the regard that some one can use ECA at all ATM.</td> </tr> <tr> <td>mxh</td> <td>The most powerful modeller we have right now is the BPMN io one, and I think it makes sense to at least identify that it has an a11y problem and that the upstream maintainers at least are aware of that. That's all what we can do about that with our time capabilities I guess.&nbsp;(edited)</td> </tr> <tr> <td>jurgenhaas</td> <td>OK. How about taking the eca.eca.* config file from a bpmn_io model and opening that in eca_cm? Should be possible, right?</td> </tr> <tr> <td>mxh</td> <td>@jurgenhaas Yes, converting from bpmn to cm is easy, as you don't need a model config at all. But you could lose information that only the model file has, for example condition configuration array currently don't store the label in the ECA config, that's only saved in the model data.</td> </tr> <tr> <td>rkoller</td> <td>ah thanks for clarify the difference between the core modeler and bpmn @mxh that i was not aware of. then it would be best to document all open a11y issues (even the &ldquo;make the diagram browse and graspable&rdquo; for screenreader users issue).&nbsp;(edited)</td> </tr> <tr> <td>mxh</td> <td>Opening the eca.eca.* with the core modeller is currently not intended to do so, because then you'd store changes in the eca.eca.* file but that would then be out of sync with the model data of the bpmn model file.</td> </tr> <tr> <td>jurgenhaas</td> <td>@mxh I'm thinking about support issues and the ECA Guide Library: we could probably develop all models in that context in bpmn_io and then publish them also for eca_cm without any extra work, apart from little conversion which can be automated.</td> </tr> <tr> <td>mxh</td> <td>@rkoller yes, exactly</td> </tr> <tr> <td>rkoller</td> <td>i&rsquo;ll create a document over the weekend and list potential to dos.</td> </tr> <tr> <td>mxh</td> <td>@jurgenhaas yes that's doable, conversion would be easy as you'd just drop the model file and replace modeller: * with modeller: core in the eca.eca.* file</td> </tr> <tr> <td>mxh</td> <td>However, the created example models might be hard to understand when looking at it from the core modeller.</td> </tr> <tr> <td>jurgenhaas</td> <td>Let's continue the eca_cm topic in 3&#65039;&#8419;.3&#65039;&#8419; to keep this one on a11y</td> </tr> <tr> <td>jurgenhaas</td> <td>Looks like this is a discussion about a11y that goes pretty deep and also contains relevant links: <a href="https://forum.bpmn.io/t/how-to-make-modeler-keyboard-accessible/5996">https://forum.bpmn.io/t/how-to-make-modeler-keyboard-accessible/5996</a></td> </tr> <h2>3&#65039;&#8419;.2&#65039;&#8419;&nbsp; bpmn_io and regular upstream updates</h2> <table> <tr> <td>jurgenhaas</td> <td>How should we go about review/test on a weekly or monthly basis? There is one waiting for review already, see <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/bpmn_io/-/work_items/3302073" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/bpmn_io/-/work_items/3302073</a></span></td> </tr> <tr> <td>jurgenhaas</td> <td>But this will happen more regularly, I guess.</td> </tr> <tr> <td>rkoller</td> <td>how grave is the danger that anything breaks on weekly updates? and is it just replacing the core bpmn lib and upgrading to a newer version or is there also the need to implement new functionality?</td> </tr> <tr> <td>jurgenhaas</td> <td>This is just about updating their webpack components. No new features at our end. I want to believe that testing might be as simple as checking the UI canvas, the template chooser and one or two events or actions, if they still operate as before. If that's the case, it's hard to see that anything else could be broken.</td> </tr> <tr> <td>rkoller</td> <td>then why not try to go with a short interval of on a weekly basis. bpmn is rather active. that way positive changes from upstream would get into eca/bpmn faster. and in case that problems turn up then interval could be stretched. ( if it is a bug or individual problem on the bpmn end that interval could get back to the weekly interval. in case it is a more foundational problem then the longer interval could be kept for the time being until it is fixed?</td> </tr> <tr> <td>mxh</td> <td>You'd then need to manually test once per week, could be a bit too much maybe. Regular update once per month could be fine, except for security stuff of course.</td> </tr> <tr> <td>jurgenhaas</td> <td>Yes, I think monthly should be ok. Not only the test effort but also documenting the changes that are in a new release takes quite some time.</td> </tr> <tr> <td>rkoller</td> <td>ahhh you meant for official releases! i thought pull bpmn into bpmn_io dev releases?</td> </tr> <tr> <td>jurgenhaas</td> <td>Most likely, new releases for bpmn_io will only be triggered by upstream updates, there is no development in the pipeline on the Drupal side. I guess that's a good thing. Of course, if we need some improvement in the integration, we will of course do that. But it looks as if the integration is solid and doesn't require regular improvements.</td> </tr> <tr> <td>jurgenhaas</td> <td>But from upstream, we get a lot of changes and improvements. So this is about planning how we make them available to the Drupal users. A regular schedule might be best, because what else should trigger us doing the work?</td> </tr> <tr> <td>mxh</td> <td>yeah, I also think that's the best we can do</td> </tr> <h2>3&#65039;&#8419;.3&#65039;&#8419; eca_cm is new</h2> <table> <tr> <td>jurgenhaas</td> <td>Thanks to @mxh this is built with Drupal's form API - looks great</td> </tr> <tr> <td>mxh</td> <td>Here's the project page of that modeller: <a href="https://www.drupal.org/project/eca_cm">https://www.drupal.org/project/eca_cm</a></td> </tr> <tr> <td>jurgenhaas</td> <td>Good stuff :tada: Is there something like a roadmap for what's next or is it already kind of complete?</td> </tr> <tr> <td>jurgenhaas</td> <td>Following up on loading models from bpmn_io modeller in eca_cm: the import function in ECA could be extended such that for any model we could provide an option to import for eca_cm, because every modeller will at least provide everything that's needed for eca_cm</td> </tr> <tr> <td>jurgenhaas</td> <td>Yes, you're right that the models will be harder to understand in eca_cm, but at least users can do something with those models, even if they can't use bpmn_io or any other more complex modeller in the future.</td> </tr> <tr> <td>mxh</td> <td>Yep, that's a win I guess :slightly_smiling_face:</td> </tr> <tr> <td>mxh</td> <td>Regards roadmap: Feature-wise I currently don't plan to add more stuff into it, just fixing bugs / optimize when required</td> </tr> <tr> <td>mxh</td> <td>Some may think for extend such a modeller even further, for example using a draggable table for arranging nested conditions and actions, but that would contradict the purpose of the Core modeller and thus would need to live within another project :slightly_smiling_face:</td> </tr> <tr> <td>jurgenhaas</td> <td>Fair enough. As long as this is communicated properly, so that no other expectations are hanging around. Maybe something for the project page of eca_cm</td> </tr> <tr> <td>jurgenhaas</td> <td>Regarding the import as eca_cm, I'm going to open an issue for that and will provide a proposed implementation.</td> </tr> <tr> <td>mxh</td> <td>Yeah, I've just added some notes to the project description page.</td> </tr> <tr> <td>jurgenhaas</td> <td>For the records, here is the import issue as mentioned above: <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/eca_cm/issues/3304333" title="Status: Closed (fixed)">#3304333: Import models from other modellers into eca_cm</a></span></td> </tr> <h2>4&#65039;&#8419; eca_tamper module</h2> <table> <tr> <td>jurgenhaas</td> <td>Couple of issues waiting for review, we should release a bug fix release for them as eca tamper is currently not working at all.</td> </tr> <tr> <td>jurgenhaas</td> <td><a href="https://www.drupal.org/project/issues/eca_tamper?categories=All">https://www.drupal.org/project/issues/eca_tamper?categories=All</a></td> </tr> </table> <h2>5&#65039;&#8419; ECA Documentation&nbsp;(edited)&nbsp;</h2> <table> <tr> <td>Daniel Speicher</td> <td>I will work continuously on to doc. Going throu all modules and add doc for all the fields of our plugin templates. I prefer to add doc in the source code to have a text under the field directly in the modeller</td> </tr> <tr> <td>jurgenhaas</td> <td>Agreed, simple and short descriptions for all the plugin fields is certainly best in code so that it also goes into the UI</td> </tr> <tr> <td>jurgenhaas</td> <td>In addition, I can see quite a few plugins and/or fields that could do well with some extra conceptional explanations. They would then probably be better placed in the ECA Guide.</td> </tr> <tr> <td>Daniel Speicher</td> <td>Yes, I agree</td> </tr> <tr> <td>rkoller</td> <td>with my new computer i was finally able to copy my local apple numbers document into zoho.com sheets juergen suggested me a while ago. with the old numbers version i was unable to bring things over and in addition my computer was to slow editing the sheet in the browser then.i&rsquo;ve updated a model with all available eca modules and started to copy all the strings over. that way it was easier to see inconsistencies. i haven had time to rework the strings yet. they are drafts. some rough drafts. but i think the sheet might be in context with the docs/descriptions perhaps helpful: <a href="https://sheet.zoho.eu/sheet/open/07ou0e60959ce420d455aafb45437986b8730?sheet=Task%20-%20action&amp;range=A1">https://sheet.zoho.eu/sheet/open/07ou0e60959ce420d455aafb45437986b8730?sheet=Task%20-%20action&amp;range=A1</a> (fields with two strings means the first is the original the second the updated draft - yellow background color means no original string available, pink means a string coming from commerce - and i&rsquo;ve added the type of field in brackets usually - also added a few comments). but there are many questions from the ux end. a few i&rsquo;ve already added over in the mattermost chat before my eye issues flared up again a few weeks ago and brought everything to stop on my end.</td> </tr> <tr> <td>jurgenhaas</td> <td>@rkoller I had to create an account with zoho, but it says that the link is no longer valid, there should be a new one it says on their side</td> </tr> <tr> <td>rkoller</td> <td>oh my bad. never collaboratively used zoho sheets. thought it would be accessible out of the box. just copied the link. but took a look. there is the option to share a document (i would have to add collaborators) or publish it in general. but with the share option if clicked there is a permalink. not sure if it would be possible to edit: <a href="https://sheet.zoho.eu/sheet/open/07ou0e60959ce420d455aafb45437986b8730">https://sheet.zoho.eu/sheet/open/07ou0e60959ce420d455aafb45437986b8730</a> (and not sure yet how the team function works to inform team members)</td> </tr> <tr> <td>jurgenhaas</td> <td>That link doesn't work either. As the sheet doesn't contain secrets, maybe making it public is an option?</td> </tr> <tr> <td>rkoller</td> <td>yep but it isnt clear if it is possible to edit for everyone then and also adding comments or if it is view only. that was only available under the share label. therefor i&rsquo;ve tried to get it working first.</td> </tr> <tr> <td>rkoller</td> <td>on share you are able to grant an access level to a member by email. ( view, view&amp;comment, edit) are the three levels available&nbsp;(edited)</td> </tr> <tr> <td>rkoller</td> <td>ok if you publish the sheet it is possible to allow interactions ( in general) but those changes arent saved to the original file. what ever that means.</td> </tr> <tr> <td>rkoller</td> <td><a href="https://sheet.zohopublic.eu/sheet/published/07ou0e60959ce420d455aafb45437986b8730">https://sheet.zohopublic.eu/sheet/published/07ou0e60959ce420d455aafb45437986b8730</a></td> </tr> <tr> <td>jurgenhaas</td> <td>Oh, that's huge :laughing: - great work went into that. Maybe @Daniel Speicher could coordinate his effort in adding more strings into the code base with you on the sheet&nbsp;(edited)</td> </tr> <tr> <td>rkoller</td> <td>if you send me your email addresses you are registered at zoho i could try to add you as team members for editing permissions ( in case you have a zoho account)it is cumbersome to bring everything over to a sheet (did that twice) . but in the sheet it is easier to see and compare strings. see if they are too long as well as repeating patterns. and it is also easier for discussions probably&nbsp; to point to A77 in task actions.</td> </tr> <tr> <td>rkoller</td> <td>and in regards of accessibility we would also have to work with span in strings to hide parts of the text for sighted users but repeat certain parts for screen reader users.</td> </tr> <tr> <td>rkoller</td> <td>and a disclaimer i havent had the time to work through all the new strings that got in during the second round. so there are still many occassions of strings like Entity: create new&nbsp; will clean that up over the weekend as well hopefully.</td> </tr> <tr> <td>rkoller</td> <td>and that is the visual highlight you are able to see for the canvas when dropping an item:</td> </tr> <tr> <td>jurgenhaas</td> <td>5&#65039;&#8419; .1&#65039;&#8419; Model Library in ECA Guide</td> </tr> <h2>5&#65039;&#8419; .1&#65039;&#8419; Model Library in ECA Guide</h2> <table> <tr> <td>jurgenhaas</td> <td>More and more, we get support requests where we sometimes provide simple models to show how a requirement could be satisfied. I'd love to add such examples to the library as they are certainly great for other users to learn from. Is that OK, if we add such models from the bpmn.io modeller or do we have to provide both, eca_cm and bpmn_io?</td> </tr> <tr> <td>Daniel Speicher</td> <td>I think to have a fast and good result, it is sufficient to add from the bpmn.io.</td> </tr> <tr> <td>Daniel Speicher</td> <td>at first of course. I believe, that most of the user uses bpmn.io</td> </tr> <tr> <td>Daniel Speicher</td> <td>To build a library sounds great</td> </tr> <tr> <td>Daniel Speicher</td> <td>Is it a big effort to have models for eca_cm as well?&nbsp;(edited)</td> </tr> <tr> <td>jurgenhaas</td> <td>The library already exists BTW, <a href="https://ecaguide.org/library/">https://ecaguide.org/library/</a></td> </tr> <tr> <td>jurgenhaas</td> <td>It's more about extending it. The question about the modeller is also about a11y, see <a href="https://drupal.slack.com/archives/C0287U62CSG/p1660748435281189">https://drupal.slack.com/archives/C0287U62CSG/p1660748435281189</a></td> </tr> <tr> <td>mxh</td> <td>You could just create the example models with bpmn. Conversion from that to eca_cm would be easy, as you'd just drop the model file and replace modeller: * with modeller: core in the eca.eca.* file. @jurgenhaas already addresses that topic within its own issue</td> </tr> <h2>6&#65039;&#8419; model list page ( in particular with more than modeler installed)</h2> <table> <tr> <td>rkoller</td> <td>i&rsquo;ve noticed one potential issue. currently on the model list page each button is a primary button. usually the primary button is reserved for a single call to action. i&rsquo;ve installed now the eca_cm module and now i have 4 blue primary buttons (add new bpmn io model, add new core model, import and save)</td> </tr> <tr> <td>rkoller</td> <td>so it would make sense to make the upper three regular grey buttons and leave the save button as primary button to save the order of the models?and i wonder if it would make sense to merge the add new model buttons and let them behave like content types. the buttons text could be just add new model. with one modeler installed when the button is clicked the model in the modeler in question is created. if there is more than one modeler installed then forward to a new page like for content types where the user is able to choose add a new bpmn model or add a new core model for example?</td> </tr> <tr> <td>jurgenhaas</td> <td>That's a great suggestion, like that</td> </tr> <tr> <td>jurgenhaas</td> <td>Could you open an issue in the ECA queue for that? We should take it from there, as that would require some re-architecture of the routing system.</td> </tr> <tr> <td>rkoller</td> <td>yes will open an issue after the meeting ended.</td> </tr> <tr> <td>rkoller</td> <td><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/eca/-/work_items/3304334" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/eca/-/work_items/3304334</a></span></td> </tr> <h2>7&#65039;&#8419; one topic i forgot to bring up. its about the canvas and one detail exclusive to macos it looks like (which took me a little while to figure out)</h2> <table> <tr> <td>rkoller</td> <td>as you can see there is a grey border right next to the property pane as well as spanning across the bottom of the viewport.</td> </tr> <tr> <td>rkoller</td> <td>turned out it is because of the &ldquo;always show scroll bars&rdquo; option. for whole web pages it works out fine but in the scope of the canvas and the property pane as the key if a scrollbar is necessary on the y axis it leads to those grey bars.at first i&rsquo;ve suspected it would be because of a misplacement of the canvas. but that isnt the case.</td> </tr> <tr> <td>rkoller</td> <td>but never the less the canvas is still not perfect. would it be possible to remove the borders on the left and right? at the moment the canvas ends at some point not visible to the users. it is only apparent when you drag an item onto the canvas then the visible part gets visually colorized.</td> </tr> <tr> <td>jurgenhaas</td> <td>Is that defined in the CSS coming from BPMN.io&nbsp; or from the drupal module?</td> </tr> <tr> <td>rkoller</td> <td>as long the canvas doesnt span the whole screen minus the toolbar and header section. some visual indication might be helpful perhaps?otherwise trying to span the canvas the whole white background area?</td> </tr> <tr> <td>rkoller</td> <td>that greyish strip from the screenshot you mean where it is defined?</td> </tr> <tr> <td>rkoller</td> <td>the greyish strip disappears as soon as another setting in macos is set. so it is macos only. i only wanna research if it would be possible to prevent in case always is chosen as the setting (as used in th first screenshot) . cuz as you can see with one of the other two settings the greyish strip is gone:</td> </tr> <tr> <td>jurgenhaas</td> <td>My question was, if those visuals are caused by CSS definitions, which component that CSS was coming from. If its not CSS, then it must be the browser or the os, both of which we cant influence. I cant really help much as I'm staying as far away from macos as possible :wink:</td> </tr> <tr> <td>rkoller</td> <td>the grey bar from the first screenshot is caused by macos ( i first suspected it would be caused by some misplacement of the canvas. ) but as you could see in the second screenshot changing one setting removes the greyish strip. but i will check if there is a way to also prevent with some browser specific css to also hide that in case. and yep i am welll aware that you try to avoid and keep macos as far as possible from you :D hahabut the other point would be still valid for discussion. currently the canvas is positioned that way:you have a border on the left and right as well as the property pane &ldquo;hanging in the air&rdquo; on the right. and you also have a border to the top. the extend of the canvas isn&rsquo;t visible to the user therefor suboptimal. that was my suggestion. either somehow illustrate the canvas borders somehow or let the extend of the canvas cover the whole white background area?</td> </tr> <tr> <td>jurgenhaas</td> <td>I'm not sure I fully grasp the issue, but want to mention that the canvas is embedded in a container of the admin theme, from which we probably should not escape. That said, I'm not sure what exactly the action items should be</td> </tr> <tr> <td>rkoller</td> <td>no the container of the admin theme shouldnt be touched i agree. well the problem is on bpmn.io the extent of the canvas is spanning across the whole viewport (i&rsquo;ve added a few actions and dragged them half way outside the canvas (and screen and this case). and also underneath bpmn controls. there the user has and exact idea how far the canvas spans.</td> </tr> <tr> <td>rkoller</td> <td>in contrast on the eca end the canvas ends sooner so you have on three of four side a padding which isnt apparent to the user.</td> </tr> <tr> <td>jurgenhaas</td> <td>Right, I see that. This is because of that mentioned container, in which the canvas is embedded. I had thought about the option to use full screen for the canvas, but then the Drupal embed feeling would be lost, then a separate URL with the canvas would just be the same thing. What I'm not getting: what exactly is the issue and how would you suggest to overcome that?</td> </tr> </table></table></table></table></table></table></table></table>