>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3307297. --> Reported by: [jurgenhaas](https://www.drupal.org/user/168924) >>> <h2>0&#65039;&#8419; Who is here today?</h2> <table> <tr> <td>Daniel Speicher</td> <td>Daniel from Germany, ECA maintainer and member of LakeDrops</td> </tr> <tr> <td>jurgenhaas</td> <td>J&uuml;rgen here, also from LakeDrops in Germany</td> </tr> <tr> <td>mxh</td> <td>Max (OpenCampus) sitting in Munich :wave:</td> </tr> <tr> <td>boromino</td> <td>Richard from Lakedrops</td> </tr> <tr> <td>rkoller</td> <td>:wave: ralf from n&uuml;rnberg</td> </tr> <tr> <td>saschaeggi</td> <td>Sascha from GitLab :wave:</td> </tr> </table> <h2>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> <h2>2&#65039;&#8419; Updates on the ECA Guide Library</h2> <table> <tr> <td>jurgenhaas</td> <td>I was able to fix some javascript issues which prevented the library pages from properly refreshing, sometimes. This caused issues, that also the download link wasn't updates and therefore the wrong model could have been downloaded. That's fixed now.</td> </tr> <tr> <td>jurgenhaas</td> <td>Also, we can now safely publish all sample models built with the bpmn_io modeller. The eca core modeller is now able to import them as well.</td> </tr> <tr> <td>jurgenhaas</td> <td>And last but not least, we have so many great support issues on d.o with use cases that should all be turned into sample models for the ECA Guide. I think this is the best way for others to learn the concepts of ECA.</td> </tr> </table> <h2>Context for conditions/actions&nbsp;(edited)&nbsp;</h2> <table> <tr> <td>jurgenhaas</td> <td>Hi @boromino are you referring to this one? <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/eca/-/work_items/3279349" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/eca/-/work_items/3279349</a></span></td> </tr> <tr> <td>boromino</td> <td>Yes, exactly.</td> </tr> <tr> <td>boromino</td> <td>However I guess this has to include the javascript side, too. I recall that camunda mentioned something about context in their library.</td> </tr> <tr> <td>jurgenhaas</td> <td>Yes, the implementation will have to be done in javascript, that's actually not that difficult. Once we have the context defined in ECA, we can then add that information to the templates, which are forwarded to the BPMN.iO modeller as JSON. Changing the content of the drop-down template chooser is then pretty easy. I fear that defining context for things that are not always known might be more difficult.</td> </tr> </table> <h2>3&#65039;&#8419;Status of the next &ldquo;bigger&rdquo; release, supposed to be 1.1.0. We have some really cool improvements in the issue queue. Maybe, we can make a soft prioritization</h2> <table> <tr> <td>jurgenhaas</td> <td>Sounds like a good idea.</td> </tr> <tr> <td>Daniel Speicher</td> <td>I know, that this might be impossible due to the amount</td> </tr> <tr> <td>Daniel Speicher</td> <td>of issues.</td> </tr> <tr> <td>jurgenhaas</td> <td>Well, I don't feel much pressure for a feature release. 1.0 is really stable and for projects that need some of the new features that already landed in 1.1.x I don't mind using that. So, we could just keep going, as implementing those new features requires resources that currently seem very limited. And once we have burned down the issue queue, it might be the right time for the next release.</td> </tr> <tr> <td>jurgenhaas</td> <td>But if we wanted to push harder, I'm ok with that too</td> </tr> <tr> <td>Daniel Speicher</td> <td>I think we can talk, when something gets really important.</td> </tr> <tr> <td>mxh</td> <td>One thought a that came up was, when we're ready for 1.1.0, that we first create a 1.0.0-rc1, wait for a week, and then release 1.1.0 stable when no problems were reported.</td> </tr> </table> <h2>4&#65039;&#8419; bpmn_io accessibility: any progress since last meeting?</h2> <table> <tr> <td>rkoller</td> <td>from my end nothing to show yet. have a few things in parallel currently. but started to look through the bpmn_io interface listing things i notice. and in the next step will go through the bpmn io issue queue and see what already has issues. and in case there arent open some</td> </tr> <tr> <td>jurgenhaas</td> <td>Great, thanks Ralf</td> </tr> </table> <h2>5&#65039;&#8419; ECA Guide Best Practices</h2> <table> <tr> <td>jurgenhaas</td> <td>Also as an outcome from support in the issue queue, we're collecting some knowledge that we should capture in the guide. And users start asking for "Best practices" in particular. My question is: how should we decide about what is and what isn't a best practice?</td> </tr> <tr> <td>Daniel Speicher</td> <td>Good question. Shall we try to collect proposals and decide based on them?</td> </tr> <tr> <td>boromino</td> <td>I think the library is a good way to do it. Above all because there might be different solutions to the same requirement. Similar to IT cookbooks.</td> </tr> <tr> <td>jurgenhaas</td> <td>Yes, there are always different ways to do certain things. But don't you think we as the "ECA experts" should recommend THE best way to do certain things if it's under the heading "Best practice"?</td> </tr> <tr> <td>jurgenhaas</td> <td>But maybe it's also OK to present alternative "Best practices" and describe in addition what the pros and cons are for each of them.</td> </tr> </table> <h2>6&#65039;&#8419; Status of documentation: I will continue with the code based user doc next week. I also try to use the documentation rkoller has done already. This is really useful!</h2> <table> <tr> <td>rkoller</td> <td>i havent had time to continue on the spreadsheet (many of the new strings are just pasted in as is and havent got updated yet with a suggestion). but i wonder if it would make sense to have a video or audio call to talk about the documentation as well as all the labels for the fields. also in the context of usability and comprehension for users as well as devs.&nbsp; and there are also the questions in the mattermost chat that might be relevant from a usability perspective as well.</td> </tr> </table> <h2>7&#65039;&#8419; BPMN.iO issue: how to arrange Drupal components around the canvas</h2> <table> <tr> <td>jurgenhaas</td> <td>There is this issue <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/bpmn_io/-/work_items/3304680" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/bpmn_io/-/work_items/3304680</a></span> from @rodmarasi</td> </tr> <tr> <td>jurgenhaas</td> <td>This needs some input from UX experts</td> </tr> <tr> <td>rkoller</td> <td>i&rsquo;ve installed the webprofiler. but when i tried to open the everything model i run into an unexpected error. it doesnt want me to test that :D</td> </tr> <tr> <td>rkoller</td> <td>will open an issue after the meeting. currently is also the project browser meeting alongside still</td> </tr> <tr> <td>rkoller</td> <td>The website encountered an unexpected error. Please try again later.<br> TypeError: Cannot assign Drupal\webprofiler\Entity\Decorators\Config\ConfigEntityStorageDecorator to property Drupal\parameters\ParameterRepository::$collectionStorage of type Drupal\parameters\Entity\ParametersCollectionStorage in Drupal\parameters\ParameterRepository-&gt;__construct() (line 82 of modules/contrib/parameters/src/ParameterRepository.php).<br> Drupal\parameters\ParameterRepository-&gt;__construct(Object, Object, Object, 1) (Line: 262)<br> Drupal\Component\DependencyInjection\Container-&gt;createService(Array, 'parameter.repository') (Line: 176)<br> Drupal\Component\DependencyInjection\Container-&gt;get('parameter.repository') (Line: 37)<br> Drupal\eca_parameters\Plugin\ECA\Condition\ParameterExists::create(Object, Array, 'eca_parameter_exists', Array) (Line: 21)<br> Drupal\Core\Plugin\Factory\ContainerFactory-&gt;createInstance('eca_parameter_exists', Array) (Line: 83)<br> Drupal\Component\Plugin\PluginManagerBase-&gt;createInstance('eca_parameter_exists') (Line: 110)<br> Drupal\eca\Service\Conditions-&gt;conditions() (Line: 541)<br> Drupal\eca_modeller_bpmn\ModellerBpmnBase-&gt;getTemplates() (Line: 76)<br> Drupal\bpmn_io\Plugin\ECA\Modeller\BpmnIo-&gt;edit() (Line: 206)<br> Drupal\eca_ui\Controller\EcaController-&gt;edit('process_z6jzc9k')<br> call_user_func_array(Array, Array) (Line: 123)<br> Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 564)<br> Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 124)<br> Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)<br> Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 159)<br> Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 81)<br> Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 58)<br> Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 48)<br> Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 106)<br> Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 85)<br> Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 50)<br> Drupal\ban\BanMiddleware-&gt;handle(Object, 1, 1) (Line: 48)<br> Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 38)<br> Drupal\webprofiler\StackMiddleware\WebprofilerMiddleware-&gt;handle(Object, 1, 1) (Line: 51)<br> Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)<br> Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 709)<br> Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)should the report go to the eca_parameters module?</td> </tr> <tr> <td>jurgenhaas</td> <td>Maybe, maybe not. Just opening an issue somewhere to get started is best, we can still move it around when needed.</td> </tr> <tr> <td>jurgenhaas</td> <td>But is that related to this thread? Also, the webprofiler doesn't seem to be need for this thread, does it?</td> </tr> <tr> <td>rkoller</td> <td>the initial start of the issue was because the webprofiler was hiding the browse tokens link. that i wanted to test and ran into the error ;)</td> </tr> <tr> <td>jurgenhaas</td> <td>Ah, got it. I skipped that part completely because I thought that moving those components up to the top right corner like we already have that in Gin, would resolve it.</td> </tr> <tr> <td>rkoller</td> <td>ah oki. i always test in claro. that is my initial benchmark.</td> </tr> <tr> <td>jurgenhaas</td> <td>However, there are other things that interfere with that, like a status bar for a stage indicator. That usually sits at the top of the browser windows and pushes everything else down, except our components over there. Then things look disarranged as well.</td> </tr> <tr> <td>jurgenhaas</td> <td>Maybe a generic approach would make sense, for both Claro and Gin. Maybe @saschaeggi could give us some advise with this? I mean, maybe there's already some markup and/or CSS which we just would have to use and the problem went away without extra effort.</td> </tr> <tr> <td>saschaeggi</td> <td>for Gin we have.your-fixed-item {<br> position: fixed;<br> top: var(--ginHorizontalToolbarOffset, 0); // top offset<br> left: var(--ginVerticalToolbarOffset, 0); // left offset<br> width: calc(100% - var(--ginVerticalToolbarOffset, 0px));<br> }available if I understood correctly</td> </tr> <tr> <td>jurgenhaas</td> <td>That's exactly what I was looking for, thanks Sascha. It means that we inherit all the logic from Gin - and if there should be any conflict with other components, then we will benefit from a potential fix automatically as well.</td> </tr> <tr> <td>jurgenhaas</td> <td>Wondering if anything similar were also available for Claro?</td> </tr> <h2>8&#65039;&#8419; BPMN.iO issue: better handling of component types</h2> <table> <tr> <td>jurgenhaas</td> <td><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/bpmn_io/-/work_items/3306730" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/bpmn_io/-/work_items/3306730</a></span></td> </tr> <tr> <td>jurgenhaas</td> <td>I'd like to get some opinions on that one</td> </tr> <tr> <td>Daniel Speicher</td> <td>We can hide the symbol. Do we have any need to change the type? Are there use cases for it?</td> </tr> <tr> <td>jurgenhaas</td> <td>Good question, I'm not sure TBH. I also thought, hiding is best. On the other hand, each type comes with different symbols and hat might be good for a better overview. But I'm not sure, if the different types comes with other dependencies or complications somewhere down the road.</td> </tr> <tr> <td>Daniel Speicher</td> <td>Ok. But that can be done, when someone asks for?</td> </tr> <tr> <td>jurgenhaas</td> <td>Good point, yes.</td> </tr> </table> <h2>9&#65039;&#8419; Playing the numbers game: some statistics</h2> <table> <tr> <td>jurgenhaas</td> <td>Usage statistics for ECA 1.0</td> </tr> <tr> <td>Daniel Speicher</td> <td>Really cool!</td> </tr> <tr> <td>jurgenhaas</td> <td>Issue queue analysis</td> </tr> <tr> <td>jurgenhaas</td> <td>Number of unique visitors on ECA Guide daily</td> </tr> <tr> <td>jurgenhaas</td> <td>Looks like a quarter (20-30) of the users (140) is visiting the ECA Guide once a day. Sounds like it's an important tool.</td> </tr> <tr> <td>Daniel Speicher</td> <td>yes, it is. So the motivation is very high to work on that.</td> </tr> </table> </table>