>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3320754. --> 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>jurgenhaas</td> <td>J&uuml;rgen from LakeDrops, ECA maintainer.</td> </tr> <tr> <td>mxh</td> <td>Max from OpenCampus</td> </tr> <tr> <td>Daniel Speicher</td> <td>Daniel for LakeDrops</td> </tr> <tr> <td>Bart Verheyde</td> <td>Bart from Ghent University/ Leopard Solutions</td> </tr> <tr> <td>rkoller</td> <td>:wave: ralf</td> </tr> <tr> <td>snable</td> <td>:wave:</td> </tr> <tr> <td>eidoscom</td> <td>:wave:</td> </tr> </table> <h2>2&#65039;&#8419; Road to ECA 1.1 - what needs to happen and when?</h2> <table> <tr> <td>jurgenhaas</td> <td>Main new feature is ECA Render: <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/eca/-/work_items/3281715" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/eca/-/work_items/3281715</a></span></td> </tr> <tr> <td>jurgenhaas</td> <td>There is so much in it, I wish we could get a couple of real tests on them so that we can be certain, that the new plugins have the "right" structure moving forward. Because changing them later would be extremely difficult or imposssible, depending on up-take.</td> </tr> <tr> <td>mxh</td> <td>Yeah, lots of stuff. We could start with a beta release, and when no problem occurs within a week, go to rc and after another week to stable.</td> </tr> <tr> <td>jurgenhaas</td> <td>Yeah, but maybe starting with an alpha? Wondering because we may have to change the API and that would not be nice if it already were beta</td> </tr> <tr> <td>jurgenhaas</td> <td>On the other hand, if it won't get tested, we may not even notice</td> </tr> <tr> <td>mxh</td> <td>My estimation is that we won't really need a major API breaking change, but bug fixes for sure. But I'm also fine by starting with an alpha first</td> </tr> <tr> <td>mxh</td> <td>Think this issue should get in before first release: <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/eca/-/work_items/3318189" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/eca/-/work_items/3318189</a></span></td> </tr> <tr> <td>mxh</td> <td>And this one would be great to be in 1.1 already: [#3318510]However not a blocker for 1.1.</td> </tr> <tr> <td>jurgenhaas</td> <td>Regarding the form killer, should that be back ported to 1.0.x?</td> </tr> <tr> <td>jurgenhaas</td> <td>Agreed on the condition extension, I can take that on as I have done it for core actions as well.</td> </tr> <tr> <td>mxh</td> <td>I'd say yes, the form killer issue can be backported. It's a behavior change, but logically it makes more sense in accordance to the behavior of Drupal's form submitter service</td> </tr> <tr> <td>jurgenhaas</td> <td>OK, let's wait for the review and if all goes well, I'll back port to 1.0.x and tag another release there. And for 1.1.x I'm going to tag the alpha and we should then advertise thses new features and hope to get some feedback from non-developers :wink:</td> </tr> <tr> <td>mxh</td> <td>sounds good+</td> </tr> </table> <h2>3&#65039;&#8419; Feedback from everybody in the channel on how things could be improved, would be awesome. Don't be shy, it's perfectly OK to comment here or even start your own topics.</h2> <table> <tr> <td>Bart Verheyde</td> <td>GUI improvement: available tokens(now you see the default global list), of the specific entity in the action for example, see the available defaults, now i see in debug witch are listed and drill down with looking up on the contenttype with devel</td> </tr> <tr> <td>jurgenhaas</td> <td>That would be a major improvement, yes. At the same time, probably one of the hardest to get done :wink:</td> </tr> <tr> <td>Bart Verheyde</td> <td>you asked :grin:</td> </tr> <tr> <td>jurgenhaas</td> <td>Touch&eacute; &#128578;</td> </tr> </table> <h2>4&#65039;&#8419; Roadmap for 1.2.x</h2> <table> <tr> <td>mxh</td> <td>Suggestion: main topic could be improving accessibility</td> </tr> <tr> <td>mxh</td> <td>The roadmap could be summarized similar we did for our stable roadmap</td> </tr> <tr> <td>jurgenhaas</td> <td>WRT accessibility, ECA will have to provide some groundwork, i.e. under the hood stuff but nothing that will then impact the UI at all. Once ECA will have done that, the real benefit will only be possible when modellers pick that up and build on top of that, right?</td> </tr> <tr> <td>jurgenhaas</td> <td>I'd like to address <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/eca/-/work_items/3307337" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/eca/-/work_items/3307337</a></span> at the same time too. It should help us making the form API usage in plugins more consistent and avoid redundant code where possible.</td> </tr> <tr> <td>mxh</td> <td>It depends on the solution path we choose to go for, whether modellers would need to do additonal work to apply new a11y features.</td> </tr> <tr> <td>mxh</td> <td>Sure, I'd actually see that issue also as part of a11y as it would most likely make our token form fields more consistent</td> </tr> <tr> <td>rkoller</td> <td>in regards of accessibility. i am kind of stuck at the moment uncertain how to report the issues upstream (aside too many things in parallel currently). if it would be best to report at bpmn or the properties panel or the template chooser.&nbsp; think the easiest might be to write up a summarized list. cuz a few points apply all of the three some only one out of the three and so forth. really complicated to create an actionable feedback for the bpmn folk. and some of the points were already voiced in here. <a href="https://forum.bpmn.io/t/how-to-make-modeler-keyboard-accessible/5996/5?u=nikku">https://forum.bpmn.io/t/how-to-make-modeler-keyboard-accessible/5996/5?u=nikku</a></td> </tr> <tr> <td>jurgenhaas</td> <td>@rkoller leveraging existing issues is probably better from the perspective of a maintainer. And if something is not addressed anywhere yet, then new issues would be required. Personally, in those cases I'd prefer "small"ish issues, i.e. only addressing one requirement each - the more focused an issue and the quicker a requirement can be grasped, the more likely that somebody picks it up.</td> </tr> <tr> <td>rkoller</td> <td>hm and where would you report a smallish issue that applies to two components for exampl bpmn and the properties panel for example? open an issue in each or open an issue in one of them and leave a note that it probably applies to another component in bpmn and leave it up to the maintainers there?</td> </tr> <tr> <td>jurgenhaas</td> <td>Probably in the main project, I'm sure they will tell you otherwise and an issue is quickly moved, if needed.</td> </tr> </table> <h2>5&#65039;&#8419; Integration with Symfony Mailer</h2> <table> <tr> <td>jurgenhaas</td> <td>Sending emails seems to be the most interesting topic when working with ECA - according to support requests and issue queue. On top of that, I recall at least 3 cases where users showed interest in symfony_mailer support.</td> </tr> <tr> <td>jurgenhaas</td> <td>Is there a way we can coordinate those efforts and move forward?</td> </tr> <tr> <td>jurgenhaas</td> <td><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/eca/-/work_items/3318907" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/eca/-/work_items/3318907</a></span></td> </tr> <tr> <td>mxh</td> <td>Added a comment in that issue. If a developer may try to address a proper integration (if needed), I'm happy to help.</td> </tr> <tr> <td>eidoscom</td> <td>I started a boilerplate for integration but some company work make me stop and I don't know when I will be able to continue.It seems that the users comenting on the issue are already sending mails but there are some HTML encoding issues.... I tried some ECA Tamper acions to see if it can be corrected with no lucky at all...I think it is necessary to create an extra "ECA Symfony Mailer" module to achieve the correct handling of this.As commented weeks ago with @jurgenhaas: First thoughts are creating an action about this and let ECA fill the different fields defined by the type of mail in Symfony Mailer. Those fields has to be dynamically loaded by ECA UI.&nbsp;(edited)</td> </tr> <tr> <td>eidoscom</td> <td>I think in this link are the keys to achieve what we are dicussing here<a href="https://www.drupal.org/docs/contributed-modules/symfony-mailer-0/development/emailbuilder-developmentI">https://www.drupal.org/docs/contributed-modules/symfony-mailer-0/development/emailbuilder-developmentI</a> get a little bit lost btw but as I said before, I have no time at the moment to spend here :S&nbsp;(edited)</td> </tr> <tr> <td>eidoscom</td> <td>We have to create the ECA Symfony Mailer module that should:Define an EmailBuilder Plugin that defines an ECA specific Policy.Almost has to have the elements from, to and body. Others can be taken in consideration but I think it is better to be defined directly in Symfony Mailer Policies UI.We have to register this Policy in Drupal core actions as it will be available in ECA UI the same way the send e-mail default action is available nowCreate an ECA Action that sends the e-mail and handles the Policy elements in the ECA UI formSeems very straightforward&nbsp;(edited)</td> </tr> <tr> <td>mxh</td> <td>@eidoscom great information, feel free to copy-paste this into the linked issue, so we have one place where we can bundle any resources together.</td> </tr> <tr> <td>eidoscom</td> <td>Shall we start the new module and put on drupal.org? @joelseguin commented he is on it and It will be better to not duplicate tasks</td> </tr> <tr> <td>mxh</td> <td>Let's first summarize all knowledge in the linked issue above and eventually start a new module if necessary from there</td> </tr> <tr> <td>eidoscom</td> <td>cool</td> </tr> <tr> <td>eidoscom</td> <td>done :wink:</td> </tr> <tr> <td>mxh</td> <td>:+1:</td> </tr> <tr> <td>eidoscom</td> <td>It is possible that I missunderstood something about all the issue so let's discuss all there <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/eca/-/work_items/3318907" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/eca/-/work_items/3318907</a></span>#comment-14780054</td> </tr> </table> <h2>6&#65039;&#8419; Circular dependencies with another contrib module</h2> <table> <tr> <td>jurgenhaas</td> <td><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/eca/-/work_items/3318655" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/eca/-/work_items/3318655</a></span></td> </tr> <tr> <td>jurgenhaas</td> <td>Any ideas what we could do about that one?</td> </tr> <tr> <td>jurgenhaas</td> <td>Summary: the token decorator from ECA uses the logger service - mainly for debugging. Problem is that the filelog contrib module uses tokens for logging.</td> </tr> <tr> <td>jurgenhaas</td> <td>This causes 2 contrib modules to not working together at all. Currently you can only use one or the other. Maybe not a big deal, but maybe somebody has some thoughts if this could be prevented from happending=</td> </tr> <tr> <td>mxh</td> <td>I don't know of a general solution for this. Think the only way to avoid such problem is to "unplug" some service dependencies, by fetching the service with a static method instead of using dependency injection in the constructor.</td> </tr> <tr> <td>mxh</td> <td>.. which in turn is not so good for testability / inversion of control principle, but I think avoiding such errors should be more important than following that principle.</td> </tr> <tr> <td>jurgenhaas</td> <td>Is there any performance impact? Just because the logger is used really a lot. But then, loading the service is only done one, right?</td> </tr> <tr> <td>mxh</td> <td>The service instantiation would only happen once per runtime, I don't think we need to think about performance. For this specific error, the affected part is at Drupal\eca_form\Token\CurrentFormDataProvider, where we need to remove the EcaExecutionFormSubscriber from the constructor argument list, and instead grab that service with the already existing method Drupal\eca\EventSubscriber\EcaExecutionFormSubscriber::get()</td> </tr> <tr> <td>jurgenhaas</td> <td>I think there was another place too. In the token decorator, aren't we loading the logger service there too?</td> </tr> <tr> <td>mxh</td> <td>I don't see that the decorator gets the logger factory as an argument from the service definition.That happens indirectly, as the token decorator collects those token data providers, and one of them is the mentioned above, which in turn causes the circular reference.</td> </tr> <tr> <td>jurgenhaas</td> <td>I see. What I suspected above is just the other way round: our ConfigurableLoggerChannel service requires the token service, which we didn't inject but also load once per runtime when needed.</td> </tr> <tr> <td>mxh</td> <td>True for the other way around, ConfigurableLoggerChannel also makes use of the token service. However that usage is outside of the service definition already, I don't think that we have a problem at that point.</td> </tr> </table>