>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3309984. --> 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>Daniel Speicher</td> <td>This is Daniel from Germany, ECA maintainer</td> </tr> <tr> <td>jurgenhaas</td> <td>J&uuml;rgen here, also ECA maintainer</td> </tr> <tr> <td>mxh</td> <td>Max from Offenburg, Germany :wave:</td> </tr> <tr> <td>rkoller</td> <td>:wave: ralf from n&uuml;rnberg</td> </tr> <tr> <td>eidoscom</td> <td>Albert from Catalonia (Spain) walking with my kids ATM :wave:</td> </tr> </table> <h2>2&#65039;&#8419; Current situation with ECA support</h2> <table> <tr> <td>jurgenhaas</td> <td>Looks like ECA is being used by more and more sites every week and we feel that in the issue queue and here in the Slack channel. I mean, this is great, and I'm really impressed how well people can obviously achieve working models.</td> </tr> <tr> <td>Daniel Speicher</td> <td>First of all, thank you guys for this great effort!</td> </tr> <tr> <td>jurgenhaas</td> <td>The fact, that we get more and more specific question isn't bad either, because it's the best input for us to learn what needs to be made better in the software.</td> </tr> <tr> <td>jurgenhaas</td> <td>Sounds to me, that any effort we can put into documentation, tutorials, blog posts, sample models, video recordings, etc. is pretty important to move forward. Knowledge transfer is the key to scale this eco system, isn't it?</td> </tr> <tr> <td>Daniel Speicher</td> <td>J&uuml;rgen, you told me that users, which are not maintaining the module, try to answer questions as well. I think, this is also a very good development.</td> </tr> <tr> <td>jurgenhaas</td> <td>Oh yes, absolutely. Every helping hand is more than welcome :slightly_smiling_face:</td> </tr> <tr> <td>mxh</td> <td>:+1:</td> </tr> </table> <h2>3&#65039;&#8419; Dependency issue regarding Drupal &lt; 9.3 needs some feedback</h2> <table> <tr> <td>jurgenhaas</td> <td>This is the issue: <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/eca/-/work_items/3308508" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/eca/-/work_items/3308508</a></span></td> </tr> <tr> <td>mxh</td> <td>Posted some feedback</td> </tr> <tr> <td>jurgenhaas</td> <td>:thankful:</td> </tr> <tr> <td>eidoscom</td> <td>I agree with @mxh point of view. It seems better to put efforts on going on and not resolving issues for unsupported core versions</td> </tr> </table> <h2>4&#65039;&#8419; Time for a 1.1.0 release schedule?</h2> <table> <tr> <td>jurgenhaas</td> <td>Especially this issue from @mxh contains a lot of new functionality: <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>From discussions with some users, I got the impression that support for routes, forms and render API is such a big deal, that "just" those 3 could qualify for a minor release. Thoughts?</td> </tr> <tr> <td>Daniel Speicher</td> <td>Would be cool. I mentioned it already last time. Think this is a good idea to provide important functionality fast.</td> </tr> <tr> <td>Daniel Speicher</td> <td>Can wen collect those issues and create a small plan?</td> </tr> <tr> <td>jurgenhaas</td> <td>It's probably just that single one linked above, that contains all 3 areas.</td> </tr> <tr> <td>jurgenhaas</td> <td>And a couple more have already been committed in the past few weeks</td> </tr> <tr> <td>Daniel Speicher</td> <td>Ah ok. But then, I vote for a minor release</td> </tr> <tr> <td>mxh</td> <td>Guess this should also be included: [#3306136]But in summary I agree to put these ones into 1.1.0. I'd suggest to go for 1.0.0-rc1 for a week, and if no problems occurred we push a stable relaese.&nbsp;(edited)</td> </tr> <tr> <td>jurgenhaas</td> <td>Agreed, so both of them are currently waiting for me to review them.</td> </tr> <tr> <td>mxh</td> <td>No pressure :wink: that render issue is a huge monster though. If some more people could have a look into it, that would help us getting it forward. I'd estimate since the vast number of new plugins, that bugs may be hiding in there, but for that reason we can make use of a release candidate.</td> </tr> <tr> <td>jurgenhaas</td> <td>Good idea. So, instead of reviewing the code line by line, what would help is to actually install and use those plugins?</td> </tr> <tr> <td>mxh</td> <td>Yes, absolutely :slightly_smiling_face:</td> </tr> <tr> <td>jurgenhaas</td> <td>As a MR or patch could be a hurdle for some, I could review the MR in a way where I look into the overall structure and naming of things, then we could quickly get this merged into the 1.1.x-dev release which will then be much easier for others to test this. Does that make sense?</td> </tr> <tr> <td>mxh</td> <td>yes, can be an approach</td> </tr> <tr> <td>mxh</td> <td>right now the only plugins that don't have an automated test are the new events, but at least I once manually tested them. Problem is that I currently don't have time resources available to add them.</td> </tr> <tr> <td>jurgenhaas</td> <td>Fair enough. I remember that testing events is not that easy anyways but we had agreed, that our test which builds the templates goes through all the event plugins as well so that we get them tested at least for syntax and deprecation that way. What's not tested then is the trigger, but that's not in scope of ECA to some extend.</td> </tr> </table> <h2>5&#65039;&#8419; Welcome @eidoscom as a new contributor, his first commit landed early this week.</h2> <table> <tr> <td>Daniel Speicher</td> <td>Yes! This was really cool. He wrote documentation for the ECA views module.</td> </tr> <tr> <td>eidoscom</td> <td>Oh I'm very grateful for this welcome. I appreciate and believe in the power of this module. I was a hard rules user in D7 times.Hope I can continue bringing time to the project as I learn to use. I applied some quite complex logics using ECA in a project and it turned to be a lifechanger :slightly_smiling_face:</td> </tr> </table> <h2>6&#65039;&#8419; Need some thoughts about timezones</h2> <table> <tr> <td>jurgenhaas</td> <td>Here is the issue <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/eca/-/work_items/3309543" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/eca/-/work_items/3309543</a></span></td> </tr> <tr> <td>jurgenhaas</td> <td>First guess, date and time values should always be stored in UTC, and timezones should only every come into consideration when the values get displayed, but not for storage.</td> </tr> <tr> <td>Daniel Speicher</td> <td>Should date and time not be stored in INTEGER values?</td> </tr> <tr> <td>mxh</td> <td>Integer is usually a Unix timestamp, which implies UTC. However it's also valid to specify date and time by using a certain format, like 2022-14-09 17:27T+2GMT or something :smile:</td> </tr> <tr> <td>jurgenhaas</td> <td>And unfortunately, the Drupal core datetime fields tend to store them in text format, never understood why that makes any sense</td> </tr> <tr> <td>mxh</td> <td>I mean if a user of ECA gives a formatted date string that includes the timezone info, we should be able to handle it. We could think about converting it into UTC though when storing it as configuration.</td> </tr> <tr> <td>mxh</td> <td>Yeah, probably because the supported database engines differ too much regarding datetime handling.</td> </tr> <tr> <td>jurgenhaas</td> <td>Yes, they do - in my opinion the databases should not handle datetime at all other than sorting, but that's probably off-topic :wink:</td> </tr> <tr> <td>mxh</td> <td>problem is then what the specified format should be. One way is to look up configured date formats, e.g. core.date_format.long and use that format then</td> </tr> <tr> <td>mxh</td> <td>and providing a description in the config input field, which format needs to be used</td> </tr> <tr> <td>mxh</td> <td>or maybe it's even possible to let the user decide which format to use, but think it's also fine to just use one default format</td> </tr> <tr> <td>jurgenhaas</td> <td>Those formats are used for rendering, aren't they? They are not used for storage formats in the database. The latter should be defined in the field config, I thought.</td> </tr> <tr> <td>mxh</td> <td>yes maybe, these configured formats were just one thought. But could be that they actually don't help us here</td> </tr> <tr> <td>jurgenhaas</td> <td>Maybe, we need a new action to format a timestamp with some options and store the result in a token, which can then e.g. set as an entity field value. Such a plugin sounds like an ideal candidate for a new tamper plugin TBH.</td> </tr> <tr> <td>mxh</td> <td>sounds good!</td> </tr> <tr> <td>jurgenhaas</td> <td>OK, I'm creating an issue in the tamper project and provide a spec and an MR there.</td> </tr> <tr> <td>jurgenhaas</td> <td>As for the spec, I guess timezone for input and out value and the format pattern are the options required to achieve most if not all in that context?</td> </tr> <tr> <td>mxh</td> <td>probably one input for specifying the date format is already sufficient, as the format itself can contain the timezone info already (using a T as documented here: <a href="https://www.php.net/manual/de/datetime.formats.date.php">https://www.php.net/manual/de/datetime.formats.date.php</a>)&nbsp;(edited)</td> </tr> <tr> <td>mxh</td> <td>Maybe a target time zone as additional input?</td> </tr> <tr> <td>mxh</td> <td>if that's not specified, the runtime could then automatically convert it to the default timezone of the PHP runtime</td> </tr> <tr> <td>jurgenhaas</td> <td>I thought, the input value could be a timestamp (integer) as an example and the model should tell, if that's a value in the user's timezone, or the sever's timezone or any other fixed timezone. Similar to the settings in user config, where you can select what timezone will be set by default for new users.</td> </tr> <tr> <td>jurgenhaas</td> <td>one input for specifying the date format is already sufficient, as the format itself can contain the timezone info alreadyWhat if the output format is a timestamp?And the T instruction requires a given timezone, but we probably want a dynamic one, e.g. user's or server's TZ&nbsp;(edited)</td> </tr> <tr> <td>mxh</td> <td>then it looks like we need a setting that allows to specify whether it's a timestamp or a formatted date</td> </tr> <tr> <td>mxh</td> <td>or two tampler plugins, one for timestamp and the other one for formatted date. Specifying a time zone for a timestamp doesn't make sense, because a timestamp is always UTC</td> </tr> <tr> <td>boinkster</td> <td>Sometimes I have content that has tz stored on a field. i.e. items with a office hours field in different timezones. Would be nice to use a field's tz as context.</td> </tr> <tr> <td>jurgenhaas</td> <td>Welcome @boinkster, do you store the office hours as local values, I.e. tz related?</td> </tr> <tr> <td>jurgenhaas</td> <td><a href="https://git.drupalcode.org/project/tamper/-/blob/8.x-1.x/src/Plugin/Tamper/TimeToDate.phpThere">https://git.drupalcode.org/project/tamper/-/blob/8.x-1.x/src/Plugin/Tamper/TimeToDate.phpThere</a> is already a tamper plugin available, maybe that's what's needed</td> </tr> <tr> <td>boinkster</td> <td>Using the Office Hours module: <a href="https://www.drupal.org/project/office_hoursIt">https://www.drupal.org/project/office_hoursIt</a> doesn't have a tz but does provide a hook. Since each instance could have it's own tz, so using the time Zone field (<a href="https://www.drupal.org/project/tzfield">https://www.drupal.org/project/tzfield</a>) to capture it.&nbsp; It get complex, since ideally would consider both the tz&nbsp; of the content AND User depending on how it's displayed.</td> </tr> <tr> <td>jurgenhaas</td> <td>Oh wow, than can easily become a mess, I see.</td> </tr> <tr> <td>jurgenhaas</td> <td>If I were to start a project like that from scratch, I'd always store date and time in UTC as timestamp values. For each of the locations the tz can be defined as well. By that, the data at rest is always accurate and cannot be misinterpretated. Then, when presenting the data to a user, the decision should be much easier in which tz to render each of those dates</td> </tr> <tr> <td>jurgenhaas</td> <td>Bur for eca we can't solve that underlying issue, so we have to provide plugins to allow all the required flexibility</td> </tr> <tr> <td>boinkster</td> <td>Up to now, if I needed to compare, times, say, 8am - 5pm Monday, I'll convert those to a UTC timestamp in a custom module then do logic there. Just starting with ECA, perhaps that could be exposed as a context with custom code.</td> </tr> <tr> <td>jurgenhaas</td> <td>Or the tamper plugins can convert datetime and timestamp in both directions, then you have the same flexibility as in custom code</td> </tr> <tr> <td>jurgenhaas</td> <td>I just played a bit with the 2 tamper plugins that are already available. Here is a very simple example which can be downloaded and tested on your own Drupal site: <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/eca/-/work_items/3309543" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/eca/-/work_items/3309543</a></span>#comment-14693728</td> </tr> </table> <h2>7&#65039;&#8419; related to 2&#65039;&#8419;&nbsp; setup and run usability tests?&nbsp;(edited)&nbsp;</h2> <table> <tr> <td>rkoller</td> <td>&hellip;aside taken the indirect feedback what support requests are coming to figure out in which parts the ux could be improved i also think running some users tests might be a good idea. something the maxlength module did a while ago: <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-1"><a href="https://www.drupal.org/project/maxlength/issues/3250461" title="Status: Active">#3250461: Run usability tests</a></span> . suggested something similar a few months back also for eca. but back then it wouldnt made much sense since things were changing quite frequently and fast. but now with a stable 1.0.0. it would make more sense. back then i already wrote up a rough draft. i could revisit that then provide it for feedback and afterwards either run it in an observed manner or provide clear instructions so people could create their own screencasts where they solve the tasks and think out loud. i suppose it would provide some valuable insights how people think, how people solve problems and where are the stepping stones. (edited)&nbsp;(edited)</td> </tr> <tr> <td>jurgenhaas</td> <td>Sounds really interesting - but also time consuming. But getting that feedback would be a goldmine.</td> </tr> <tr> <td>jurgenhaas</td> <td>Any idea how to get people interested in this to spend their own time on this?</td> </tr> <tr> <td>mxh</td> <td>Yes, I think it's a good time to address this, and this approach sounds promising.</td> </tr> <tr> <td>rkoller</td> <td>well the questions and instruction i could write up. that i something that is getting done a bit easier and faster than the micro copy (and for one the user tests would also inform what kind of vocabulary people are using - something i&rsquo;Ve noticed in yesterdays NWDUG meetup). then i would need some feedback in particular about the chosen tasks requiring to set up small models (meaning which submodules would be good to be covered). and running the tests wouldnt also be too time consuming. observered ones could be 5 or 10. and there is still the option in case the instructions are thorough enough to provide the option like the maxlength folks that people could record a screencast on their own. and would be an easy way to get a credit on d.o and on the other hand help to make the daily usage of eca easier for them</td> </tr> <tr> <td>jurgenhaas</td> <td>Great to hear your optimism on this. Should we maybe starting with a small set of tests? This would allow for adjustments for additional ones later on, as we learn from them about ECA itself as much as we probably learn about the tests.&nbsp;(edited)</td> </tr> <tr> <td>rkoller</td> <td>yep i agree. my draft a few months ago had 4 tasks. i would make it 6 tops now. tasks were:one task about installing eca and bpmn and everything necessary. that is an easy one. but with the many sub modules and modules eca is providing an integration for still reasonable. create a new model and give it a name. now 1- 3 small models (any wishes&nbsp; that would be of interest from your point of view touching several important aspects? ) let the user reassign an element template on an existing model.</td> </tr> <tr> <td>jurgenhaas</td> <td>Good list. And for item 3, there is a clear pattern of questions that come up in support issues in d.o - I can provide you with a list of topics that likely most people should find interesting, I guess.</td> </tr> <tr> <td>rkoller</td> <td>cool thanks. perfect.</td> </tr> </table> <h2>8&#65039;&#8419; Looking for feedback about this meeting format for ECA</h2> <table> <tr> <td>jurgenhaas</td> <td>This is the third meeting in this format and I wonder what everybody thinks about it. What's working well, what doesn't? What should be changed? Is this helpful at all? And maybe not only from the perspective of ECA maintainers, but also from others in the channel.</td> </tr> <tr> <td>rkoller</td> <td>i like the asynchronous part of the meeting that way not a whole hour is blocked and you are still able to deal with other things alongside.and i also liked that you posted the introductions thread 1&#65039;&#8419;&nbsp; alongside 0&#65039;&#8419;&nbsp; before the actual meeting started. that was good on one hand but it wasnt completely apparent that those two were posted upfront. so i thought for at least 5 to 10 minutes hmm perhaps i&rsquo;ve mixed up something timezone wise ;) but to communicate it more clearly would help perhaps. also to bring in more folks to the meetings. provide a &ldquo;suggestion box&rdquo; thread where people could voice potential problems and itches. in case they aren&rsquo;t active in the issue queue?</td> </tr> <tr> <td>jurgenhaas</td> <td>Thanks, good stuff for improvement. How about promoting the meeting in other channels like an hour before it starts? Is that to noicy?</td> </tr> <tr> <td>rkoller</td> <td>personally i consider that noisy. same as pinging the whole channel itself what happens for quite a few other weekly or biweekly meetings.&nbsp; more people will come slowly as the user base grows. so let it grow organically and let people join on their terms. and i think as soon as they have joined #eca they will notice the weekly meetings. so i wouldnt push and promote it more cross channel.</td> </tr> <tr> <td>eidoscom</td> <td>It may be interesting to add the information of the meetings on the project page. Not the content of the meetings but the format and channel used to carry them out.It would be like the "Join the team" section or even within it.In any case, as @rkoller says, organic growth will be the one that becomes more stable and productive over time.</td> </tr> <tr> <td>rkoller</td> <td>yeah add a note on the project page might be a good idea. and the pinned note here in the channel might be removed about the bbb meeting. instead something like: Next meeting: 2022-09-28 5pm CEST / 3pm UTC / 11am EST / 8am PSTand the date could be changed at the end of the meeting to the one in two weeks ( i doubt slack might have a functionality for auto adjusting dates ;)&nbsp; )</td> </tr> <tr> <td>jurgenhaas</td> <td>Good idea, I've just added something to the project page (at the very top) and also changed the sticky message here in the channel.</td> </tr> </table> <p>The "official" part of the meeting is now completed as most participants are reaching out-of-office hours. Everyone in the channel, please continue discussions in the threads above, we keep this going for the next 24 hours before the transcript will be copied into an issue on d.o</p>