>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3338672. --> 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 time zones.</h2> <table> <tr> <td>mxh</td> <td>Max from Offenburg (OpenCampus) :wave:</td> </tr> <tr> <td>boromino</td> <td>Richard</td> </tr> <tr> <td>Daniel Speicher</td> <td>Daniel from LakeDrops</td> </tr> <tr> <td>jurgenhaas</td> <td>J&uuml;rgen is here too :wink:</td> </tr> <tr> <td>rkoller</td> <td>:wave:</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; ECA version 1.2: how about making PHP 8.1 a dependency?</h2> <table> <tr> <td>Daniel Speicher</td> <td>My opinion is always a going forward strategy, but I am not sure how many potential users we prevent from using it.</td> </tr> <tr> <td>jurgenhaas</td> <td>My thought behind this: PHP 7.4 is EOL and ECA 1.2 due in a few months. Drupal installations on PHP 7.4 won't be that many by the time and those who are left will probably not serious enough for high-end solutions. And they could remain on ECA 1.1 until they get PHP 8.1</td> </tr> <tr> <td>Daniel Speicher</td> <td>There are a lot of helpul language features we can use. This reduces maintenance on the long run.</td> </tr> <tr> <td>Daniel Speicher</td> <td>Yes, end of life is&nbsp; a strong argument as well</td> </tr> <tr> <td>rkoller</td> <td>you mean with making PHP8.1 a dependency to make it the minimum requirement for eca 1.2?</td> </tr> <tr> <td>jurgenhaas</td> <td>Yes</td> </tr> <tr> <td>rkoller</td> <td>from my understanding the only problem would be sites still on drupal 9 with php 8.0 isn&rsquo;t it (php 7.4. is rather unlikely)? and drupal 9 end of life is already in november 2023. so it wouldnt be that much of a problem to make the minimum requirement for eca 1.2 to php8.1? and as you said those sites still not on php8.1 could stay on eca 1.1? and i guess eca 1.2 wont come out in the next few weeks already anyway?</td> </tr> <tr> <td>jurgenhaas</td> <td>It's probably more like a few months before 1.2 will land. So even closer to D9 EOL. And not to forget, PHP 8.0 was kinda bad - we haven't ever used that anywhere. When upgrading from PHP 7, one should go to 8.1 and skip 8.0 altogether</td> </tr> <tr> <td>rkoller</td> <td>even for me as a none developer it would make sense to make php8.1 the minimum requirement for eca 1.2 then</td> </tr> </table> <h2>3&#65039;&#8419; Still looking for feedback on gateways, see <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/eca/-/work_items/3323886" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/eca/-/work_items/3323886</a></span>&nbsp;(edited)&nbsp;</h2> <table> <tr> <td>Daniel Speicher</td> <td>This is a topic, I will have a look into soon. Tomorrow and Friday I will spend most of my time with ECA.</td> </tr> <tr> <td>mxh</td> <td>Reminds me back when gateways were added as a native part of ECA process configurations. I'd prefer to extend the way conditions and actions can be glued together, as we then operate on the three key concepts of ECA (events, conditions, actions). And BPMN could then build on top of that to realize gateways.We already have various places in ECA where gateways fall short or were completely forgotten that they also exist besides the three ones. For me that's a sign that they might not be the right choice for the key concepts. It feels like they may be a sort of helper that could provide a summary of the key components.But overall, if we'd have a good working engine that operates with gateways on the same level as events, conditions and actions, I'm also fine with that.</td> </tr> <tr> <td>Daniel Speicher</td> <td>I am 100% sure, we need a solution for the problem J&uuml;rgen mentioned. In the future I presume that a lot of models in production need a way to handle some kind of &ldquo;order&rdquo;.&nbsp; In our first big projects we came along that. The solution was a messy workaround. If Gateway is the right choice? I do not know yet.</td> </tr> <tr> <td>mxh</td> <td>Maybe we need to distinguish first what we want to achieve / which problem we want to solve, then look at possible solution concepts. That may help taking the right decisions on that.</td> </tr> <tr> <td>mxh</td> <td>The linked issue already contains a description, but IMO it involves the concept of gateways a bit too early and it kinda blocks getting an overview of possibilities (because it seems to be already decided).</td> </tr> <tr> <td>jurgenhaas</td> <td>The idea to tackle the issue in a non-BPMN fashion to design a more abstract solution is good. I think we should do exactly that in this issue and perhaps remove the specific parts out. As the description is revisioned, we won't loose that original text anyways.</td> </tr> <tr> <td>mxh</td> <td>:+1: &#128578;</td> </tr> </table> <h2>4&#65039;&#8419; Managing support requests in the issue queue</h2> <table> <tr> <td>jurgenhaas</td> <td>The volume of support requests is increasing - which is a good thing. And we provide good service quality as we respond quickly and almost always with a working solution. However, as it gets more, we should think about how to keep that level and I've seen a lot of cases, where users are rather asking a question instead of looking into the problem themselves.The most typical topic are tokens. That's probably 80% of the support requests. And almost always would the debugging tool we provide provide the answer.My suggestion is this: we could provide a support issue template in the issue queue that people need to fill out. And one section will ask for a copy of the debugging output. That way, users get reminded to do that first. And if they don't, we can go back and remind them to do that.This should help in at least 2 ways: it keeps the workload manageable for us and it help users to learn.Any thoughts?</td> </tr> <tr> <td>Daniel Speicher</td> <td>Sounds like a good start.Would it be an overcharge to request an exported model as well?</td> </tr> <tr> <td>Daniel Speicher</td> <td>I think it does not take too much time to do</td> </tr> <tr> <td>jurgenhaas</td> <td>I had thought about that too but thought, we may leave that out. Reason being, if we make the model export upload mandatory, then this creates an expectation that somebody is actually looking into it. And that's what I want to to avoid. I'd like to emphasise the learning part on the user's site. So that rather than asking for free help, spending their own time to analyse the problem as much as they can. Of course, if that doesn't work, then we're there to help.</td> </tr> <tr> <td>Daniel Speicher</td> <td>The same goes for the debug output as well. I you want the users to spend their own time, then they can analyse their debug output as well. See no difference.</td> </tr> <tr> <td>jurgenhaas</td> <td>Yes, that's what I want to achieve. And if that debug log doesn't solve the problem for them, then they should open an issue and ask us to look into it. Now I see what you mean, at that point we certainly also need the model, otherwise the log doesn't help much. Oops ...</td> </tr> <tr> <td>jurgenhaas</td> <td>Let me also re-phrase my question from the beginning: is it probably too instructive or arrogant if we introduce such rules to the issue queue?</td> </tr> <tr> <td>mxh</td> <td>I think it doesn't hurt to adjust the issue template for that. In most cases, it was about exporting the model, provide debugging output etc. so these steps mostly repeat, and thus make sense to be part of the template so we reduce such "laps of honors" &#128578;</td> </tr> </table> <h2>5&#65039;&#8419; Status of documentation</h2> <table> <tr> <td>mxh</td> <td>@jurgenhaas You requested addressing the documentation of eca_form sub-module. I've assigned this issue to me now and I hope I can bring this one forward in the near future.</td> </tr> <tr> <td>jurgenhaas</td> <td>Oh, that's amazing. TBH, I haven't tried all the wonderful actions in that sub-module and I'm staying away because being shy because I don't really know what to expect or what can be done with it. I guess, there is huge potential in it and users need to be put into a position where they know about it and are happy to use it.</td> </tr> <tr> <td>mxh</td> <td>Yeah, about time I make my first commit to ecaguide.org :wink:</td> </tr> <tr> <td>jurgenhaas</td> <td>Oh yeah :banana-dance:</td> </tr> </table> <h2>6&#65039;&#8419; General discussion about test coverage</h2> <table> <tr> <td>Daniel Speicher</td> <td>Good point. I thought it is already pretty goot. Sure, it always can be more.</td> </tr> <tr> <td>mxh</td> <td>Right now, tests are failing with the latest release tags, because one of the recent merges did not properly cover it. I'm not happy with that, and we should maybe agree that new features at least should have one automated test. To avoid future fails like the current one, maybe there is a way on the Gitlab instance that only allows to merge when all tests are green?</td> </tr> <tr> <td>Daniel Speicher</td> <td>I thought this was already the case&hellip;.ok, I was wrong than.</td> </tr> <tr> <td>jurgenhaas</td> <td>Agreed, new stuff need tests. And we missed that one failing test with the cache actions. Will fix that asap.As with test and merge automation, ECA is already able to use the GitLab-CI and I was planning to write the pipeline config for that. Then we also have control over only merging when pipeline succeeded.</td> </tr> <tr> <td>mxh</td> <td>That'd be amazing if we can configure Gitlab like that.</td> </tr> <tr> <td>jurgenhaas</td> <td>I also thought to create a test coverage report so that we can go through together and idenfiy legacy code which should also be tested moving forward.</td> </tr> <tr> <td>mxh</td> <td>:+1:</td> </tr> </table>