Provides an overview of plugins used by the ECA module.

I like this idea of the ECA plugins report. Does this represent:

• Installed plugins (not necessarily enabled)
• Installed and enabled plugins
• Installed, enabled, and some functionality in use

This sounds useful -- particularly a report of all plugins actually used by a model. Quite often I will create a custom plugin in a module for a specific site, and then contribute it to the ECA module or another module -- being able to quickly find plugins in use in custom modules so I can replace them with the versions that end up in contrib would be great!

I appreciate the immediate feedback.

For #2, similar to the Views plugin report, we should only list enabled plugins.

For #3, also similar to the Views plugin report, I added a 'Used in' to track an ECA plugin's usage.

Thank you @jrockowitz. This is extremely helpful to have these listed at one place.

This is a great ides @jrockowitz

Just want to make you aware that we're currently working on significant changes for version 3 of ECA which will be published together with Drupal core 11.2, i.e. in a few weeks. A major change will be that we introduce the generic Modeler API → which takes over not only the communications with the modeler (e.g. bpmn_io) but also takes over all router and UI from ECA. The purpose of that generic approach is that other ecosystems (e.g. Migrate, AI Agents, etc.) will be able to use the same infrastructure.

That said, it would probably make more sense to provide the "Available and used plugins" overview by the Modeler API. It would then do the same job for all the other implementors in the future as well, without any extra coding required. I'd be happy to guide you through that approach if you find this feasible.

The \Drupal\eca_report\Controller\EcaReportBaseController::getUsedIn method is relatively basic and could be reworked to support the Modeler API. At the same time, in 3.x, the ECA entity is not being changed, so we might not have to tweak any code.

My hope is that we select an MVP solution that can be easily iteratively improved without requiring additional work for the ECA maintainers.

I do see that eca_ui.module is going to change significantly with 3.x, and maybe adding this report to that module is not the best approach.

I do see that eca_ui.module is going to change significantly with 3.x, and maybe adding this report to that module is not the best approach.

That's it. Most of the UI stuff goes into Modeler API, that's what trigger my comment in #7.

Building your report in Modeler API shouldn't be too hard either.

I'd have to objection adding "ECA Report" now into ECA 2.1, if it's OK for you that it won't make it into ECA 3, as it should there being moved to Modeler API. But that migration shouldn't be too hard.

it would probably make more sense to provide the "Available and used plugins" overview by the Modeler API.

The plugins being used are defined and resided within eca.eca.* configuration entities. Modelers may not necessarily have anything to do with the plugins. Why would the modeler API to be concerned about ECA plugins? Feels more like a report sub-module to me. In the future we also might want to provide more debugging techniques that make it easier to debug running ECA processes.

@mxh the modeler API provides a framework for complex config owners, like ECA, Migrate, AI Agents, and others. They all have in common that they deal with a significant number of plugins that get configured and put in an order by a modeler.

Each of those complex config owners will have the same requirement: they would like to see the list of available plugins and where they are used. We implement that once in the modeler API, and all owners will benefit from it.

Based on #11, the new modeler API can provide a plugin usage report. The ECA Report module adds some additional columns to the reports based on the plugin type.

It might make the most sense to postpone this and leave the code in the sandbox module AS-IS.

Based on #11, the new modeler API can provide a plugin usage report. The ECA Report module adds some additional columns to the reports based on the plugin type.

That's correct, and the Modeler API can even receive more metadata from ECA about the plugin types, so it should be well equipped to create the full report.

On #12, having this report now would be quite useful. ECA 3.X is scheduled for D11.2 per #7. D10 isn't EOL until mid-late 2026. That's still a fair bit of time (potentially) at ECA 2.X.

If the consensus is that this functionality will eventually be integrated into the Modeler API and ECA (core), I could promote the sandbox to a project with the 'eca_report' namespace. The only downside of that decision is that we are establishing an 'eca_report' namespace, which might be around for only a few years.

I wouldn't be worried about the namespace.

I will promote my sandbox to a dedicated ECA report module, allowing people to contribute to it there. On the project page, I will reference this ticket.

Done!

https://www.drupal.org/project/eca_report →

Thank you @jrockowitz, I've now also added a link to that module on the project page of ECA and added it to the readme file.