Add ECA module to GovCMS

[jamesastaylor]

** What value does this module/package add to GovCMS?

In Drupal 7 / GovCMS we had access to the rules module, which I have used for a number of use cases for site administration, data cleanup and publishing automatic archival (after set period of time). It allow us to setup custom rules which would trigger based on certain events or conditions in the drupal system, that were not available out of the box in Drupal core. These rules would perform a custom automatic bulk or single action, that would help alleviate manually tasks we had to action or monitor normally. So it gave us another great tool to automate any function in the Drupal API across core and contrib modules.

The ability to setup custom rules, events triggers and actions helps us closely align functions to business rules and workflows at CASA, which would help any agency looking to do the same.

CASA high level use cases for module.

1. Ability to setup a rule to schedule a content node to be automatically unpublished /archived after a set period of time. This timeframe was set using a condition in rules for a different timeframe depending on content type and added as scheduler job when creating the node for the first time.
2. Ability to perform a bulk update to a field in content type, paragraph, taxonomy based on a pattern or condition. This has many broad reaching applications from emptying a field across all content with data so we can delete the field. To performing bulk publishing or updating to a field so a publisher does not have to manually publish across a large amount of nodes. This was previously achievable using VBO (views bulk operations) but that has been taken away in D9/10.
3. Ability to create custom rules that trigger for moderation and publishing workflows in workbench module.
4. Ability to setup rules to trigger automatic emails to a mailbox if certain conditions are met. For example if content is scheduled to be published / or unpublished it will send an automatic email to a web team mailbox notifying when this happened. So they don't have to go in and check if it did or not.

Since migrating to Drupal 9/10, the rule module was never included due to the port never being released out of alpha. At this stage this is looking less likely as the last module update for the alpha was December 2021 - https://www.drupal.org/project/rules

However it has been brought to out attention at CASA there is a replacement module available developed only for Drupal 9/10 called -https://www.drupal.org/project/eca. There is also a stable release candidate available from 1.0.7.

I have downloaded the ECA module and all other supporting sub modules to review it before submitting this module request. From what I can see the module has a even bigger feature set than the Rules module did. So it seems to tick all of the boxes for functionality we have had before. I used the basic ECA CORE modeller package instead of BPMN.IO and camunda, the later seems a little overkill and a big learning curve. The ECA core modeller is much simpler and very much like the Rules module UI in terms of Rules setup.

Data Modeller packages
BPMN.iO: JavaScript-based implementation for building models as two-dimensional diagrams, integrated into the Drupal admin UI
Camunda: user-friendly desktop client for designing and deploying automated processes
ECA Core Modeller: "low-level" modelling tool using Drupal core's form API

Included sub-modules
Installing ECA Core has no dependencies other than Drupal Core! Additional functionality with extra events, conditions and actions can be tailored to the needs of each Drupal site. Currently, these sub-modules are packaged with ECA and can be enabled individually:

• ECA Access: Events and actions to control access on entities and fields
• ECA Base: Base events, conditions and actions
• ECA Cache: Actions to read, write or invalidate cache items
• ECA Config: Config events
• ECA Content: Content entity events, conditions and actions
• ECA Endpoint - since 1.1.0: Events to define your own endpoint/routes on the fly and actions to interact with their requests and responses
• ECA Form: Form API events, conditions and actions
• ECA Log: Events and actions for Drupal log messages
• ECA Migrate: Migrate events
• ECA Misc: Miscellaneous events and conditions from Drupal core and the kernel
• ECA Queue: Events, conditions and actions for queued operations.
• ECA Render - since 1.1.0: Events and actions to work with Drupal's render API for blocks, views and all around themes and Twig
• ECA User: User events, conditions and actions
• ECA Views: Execute and export Views query results within ECA
• ECA Workflow: Content entity workflow actions

** Is the module Drupal 10 compatible?
Yes a stable release candidate (not in beta) is available for Drupal 9/10
https://www.drupal.org/project/eca

** Please provide a brief outline of what this module does.

ECA is a powerful, versatile, and user-friendly rules engine for Drupal 9+. The core module is a processor that validates and executes event-condition-action plugins. Integrated with graphical user interfaces like BPMN.iO, Camunda, ECA Core Modeller or other possible future modellers, ECA is a robust system for building conditionally triggered action sets.

ECA gets triggered for every Drupal event. It validates these events against event-condition-action models and processes all the models for the current event. Like Drupal Rules, ECA leverages existing components of Drupal core, i.e. events and actions. It comes with its own plugin manager for conditions, which results in all three components (events, conditions, actions) being available as plugins that can easily be extended by other modules. ECA models are stored in config, so they can be imported and exported via the admin UI or Drush.

ECA Core is a processing engine that runs in the background. It needs an integrated modeller – a front-end tool with which you define event-condition-action models (a.k.a. rules). ECA provides a plugin manager with an interface to easily integrate existing tools that already provide that capability. And if the modeller supports templates for events, conditions and actions, ECA will provide them for all the plugins that are available on the current Drupal site.

** Who does this module benefit:
[x ] content editors
[ x] site builders
[x ] themers
[x ] developers

Developers and site admins should be ultimately the only ones with access to manage and configure on platform.

** How could you provide/replicate the functionality of this module using alternative methods, eg in your theme?

There is no other workaround or method to achieve this functionality at the theme layer, due to level of integration in the back end administration of Drupal.

** If this module styles or alters HTML or JavaScript output, can the functionality be provided via the theme? What alternatives have you considered.

No alternatives exist and as stated above this functionality cannot be achieved at the theme layer.

** What is the maintenance and support status of the module. Describe the issue queue activity.

Being a new developed module for D9/10 only with full feature set as replacement for the rules module. The community support status for it seems quite active and the module was last updated 25 November 2022.

** What permissions are needed to utilise the module (and are any new permissions provided by the module)?
With the full feature set, there are quite a few additional permissions added to the global drupal permission sets.

** Does the module modify the database structure and/or store additional metadata on nodes or other entities? If so, why? What are the risks for future updates?

I don't think the module stores any additional metadata on other node entities, unless you setup custom rule to do this. It just utilises existing functionality and automates process between entities or functionality.

** Is the module designed to capture anonymous user data?

No, but I think there is a Rules Event log like Rules module, so you can see what it is running when...

** Is the output of the module typically fully cacheable? Would the inclusion of this module potentially render pages uncacheable.

No its purely to assist in backend administration not for front end display

** What is your assessment of the quality of this module, the contribution history of the module's maintainers, and the uptake of the module within the Drupal community?

Looks great, well supported and full rich feature set. Seems to be well maintained and held in high regard in drupal.org community based on the feed back I have read in blog articles.

Won a award this year at the splash awards.
https://www.lakedrops.com/en/blog/drupal-eca-wins-germanaustrian-splash-awards-2022

Youtube video review ECA - posted 30 November 2022
https://www.youtube.com/watch?v=DV_uxJn4w7c

** Additional information

[thisisalistairsaccount]

Hi @jamesastaylor have you got some specific uses cases round the use of ECA or things like Rules? If there's anything sensitive, please give a high level overview here and include anything more specific to us at GovCMS.

For anyone else interested, please also describe any needs you may have that could be benefitted by this module or something similar.

[jamesastaylor]

@thisisalistairsaccount Hi i have added a few high level use cases for review, from what we had setup in Drupal 7 rules module. I will try to think of more we had and add, but its a bit hard now the site has been decommissioned, without standing it up locally again.

[jamesastaylor]

@invisigoth HI J, We are trying to get more community interest and feedback for use of the ECA module as a replacement for the rules module in govCMS. Have you used it before and have any thoughts on it as a viable candidate for govCMS distro?

[larowlan]

A use case here would be allowing people to subscribe to a tender and get notifications if it was updated. You would ordinarily need to be able to write custom code to do this. But in theory could do it with ECA as a no-code solution

[xrayfish]

I've installed and used it in the PaaS setup to auto-assign specific roles/permissions after automated checks are completed. The BPMN.IO visualiser is especially helpful.

[simesy]

There are some examples with flowcharts starting with https://ecaguide.org/library/use%20case/eca_feature_demo/ - I'm looking through and there are some well known and discussed cases that are currently handled in the theme in ways that are not best practice Drupal. Adding ECA to govcms would be a significant feature expansion.

[TobyWild]

The main concern I would have (after only having seen the Community Day presentation) is the existence of https://ecaguide.org/plugins/eca/user/actions/eca_switch_account/ which could allow for some sneaky developers to create insecure hacky workarounds against the security measures currently in place.

For example, I created a new user with a new role of "ECA Only" and the only permission they had was the ability to administer ECA (Which it does say is a potential security risk).

I then created a new rule that said "Anytime someone with ECA Only logs in, promote them to Administrator role".

I would suggest we would need a Pipeline task that searches config for eca.eca.*.yml files, and if it finds the "plugin" of "eca_switch_account" being used, fail the deployment.

Probably need a full audit of all the potential actions and their potential as security risks.

Also, additional modules are required to provide the interface for adding the ECAs:

• https://www.drupal.org/project/bpmn_io
• https://www.drupal.org/project/eca_cm

[larowlan]

FWIW Plugin definitions can be altered, so one of the existing enforced security modules could remove that plugin via unset

[simesy]

https://www.drupal.org/project/bpmn_io
https://www.drupal.org/project/eca_cm

Yeah they are like Views UI module, doesn't need to be installed. And also it's not required to have both, you'd pick one. In theory they are only needed locally but I'm not sure if there's a nice way to add SaaS modules locally, is it hacking in mount points to the docker compose? I'm using eca_cm and it's not a stretch to see this added with eca, but force disabled in CI.

[TobyWild]

I think there would still be a benefit of having the UI components enabled in Production, just as with Views.
Yeh, ideally you would only ever develop stuff locally and push it out to prod via config export/deployment, but the world never runs ideally :)

[simesy]

FWIW i think the core modeller (eca_cm) is harder to use than bpmn_io, partly because all the examples use bpmn_io but mostly because it's just very hard to visualise the workflow with eca_cm. Note also that they are not interchangeable, you can't use bpmn_io to edit a workflow created with eca_cm.

I don't know about adding both. Adding this module would be a big move, and I suspect you would stick with one modeller and that should be bpmn_io.

[simesy]

Not that anything we say here has any bearing on anything. but it's definitely fun to play with.

[TobyWild]

In an attempt to prove you wrong Si, I'm going to spam this issue with SO MUCH CONTEXT, to show that raising issue's is a valid path of progress :)

@thisisalistairsaccount - More use cases for ECA

From James original post (CASA high level use cases for module):

Schedule content:
Easier and more configurable than creating and managing custom Cron tasks
Example: Setup a rule to schedule a content node to be automatically unpublished / archived after a set period of time.

Bulk updating content:
Replaces functionality previously available using VBO (Views Bulk Operations)
Example: Perform a bulk update to a field in based on a pattern or condition. such as emptying a specific field across all nodes with data so we can delete the field
Example: Performing bulk publishing or updating to a field so a publisher does not have to manually publish across a large amount of nodes.

Custom moderation rules:
Ability to create custom rules that trigger for moderation and publishing workflows in workbench module.
Example: Send an email to an approver when content enters a "For approval" workflow state.

Custom trigger rules:
Ability to setup rules to trigger automatic emails to a mailbox if certain conditions are met.
Example: Send an email when content is automatically unpublished as proof the job was completed.

Other possible examples:

More alerts
Setup alerts so that when specific events are fired (nodes are changed), emails or messages are shown.
Example: When a change is made to the homepage node, or when any users roles are changed, alert an admin.

Additional form validation:
Complex form validation for both Nodes and Webform submissions
Example: Rather than requiring custom theme hook_form_alters, additional form validation such comparing field values can be done using ECA

Custom default values:
The "Summary" field of a Textarea can be populated with a combination or subset of the other fields
Example: A user doesn't provide any text in the Summary field (Which is indexed in search) so ECA copies the title and taxonomy term names into the Summary field.

Provide custom warnings:
Although this could be provided via a custom Block with visibility set based on user role, using ECA allows the message to appear in Drupal's standard "Message" system, as well as allows for dynamic text.
Example: A message could be setup to display to any content author who logs in with a warning that the site will be in a content freeze in 5 hours time (dynamic hour count based on time calculation)

Additional record keeping:
To keep a record of all content deleted from the website.
Example: When a node is deleted, key metadata (Title, Date, User, URL, Node ID) is saved in an audit log node which tracks all content that is deleted.

[simesy]

Now i'm trying to work out what we disagreed on :D
I'll admit, I'm totally convinced bpmn_io should ship if eca ships - it's pretty darn good.

Some other thoughts:

Use case: Login redirect. Redirect different roles to different pages.

When i have access to custom code, I have noticed that some eca solutions can be overly complex, but that's exactly where they would shine on govcms. If i was setting the roadmap for govcms (which i'm most certainly not, but I like a imagine it) I would ship govcms with ECA and ship a bunch of examples above (mostly disabled) with the govcms profile.

[jurgenhaas]

My attention was brought to this issue, as I'm one of the ECA maintainers. The discussion above sounds great, and I'd like to offer our support, if there is anything that needs either clarification or even further development.

As for whether the UI should be available on production sites, I'd like to share some first-hand experience and thoughts from our end. Developers and site builders often tend to prefer custom code, since that's what they already know and how they get to working results faster. On the other hand, what makes ECA (especially together with the BPMN UI) attractive are at least 2 things:

• as ECA models are visual objects that usually explain themselves, they buy-in from stakeholders at the customer's team is much higher; in fact, this way customer are in a better position to understand, what's going on and enables them to approve the development work
• and for developers, while custom code might be preferred short term, maintainability or even hand-over to other developers or agencies should be much easier with ECA

So, not only help ECA to reduce (commercial) dependencies, it is more attractive for customers AND developers.

In addition, ECA is an enablement tool. Gov entities in Germany, as an example, are working towards no-code and low-code solutions, aiming to become more flexible when being able to design and implement workflows themselves, instead of going to developers all the time, when new or changed requirements arise. Not only does that reduce cost for governments, it also addresses the issue of developer shortages everywhere.

Of course, site security is important too. Therefore, enabling the ECA ui on a staging environment only, where new models can be created and existing ones can be modified, is something that works really well. The final and approved ECA config entities can then be deployed to production sites easily.

[simesy]

@jurgenhaas as was mentioned earlier, one of the governance issues that govcms would have is working out which actions to make unavailable. @larowlan suggested just removing out the plugins from plugin definitions. Do you have any thoughts on this from a technical governance point of view? Like what which actions might be considered a security risk?

[jurgenhaas]

@simesy there is no issue expected when somehow disabling plugins. The only potential issue that I can think of, is when you import a new ECA model through Drupal's CMI which had been created under different context with more plugins available. An ECA model knows about module dependencies, but not about plugin dependencies. A missing plugin can throw an exception during runtime. But that's a very theoretical issue in the GovCMS context, as you described it.

Having said that, disabling certain plugins (e.g. switch user context) might be too limiting, as ECA is designed to respect permissions very closely. I.e. checking a field value to verify if an ECA model should continue processing, might not be allowed for the current user and therefore, without escalating permissions, lots of workflows could not be designed without the switch user context plugin.

Now, the question is, whether you need tighter control on what privileged users can use to build ECA models, or if you need to limit what approved ECA models can execute. Let's compare this to custom code: developers, who write custom modules, have purely unlimited access and can write and later execute anything. I's compare this to those users who are allowed to build ECA models: their capabilities should be unlimited too.

That leads to the question, if the usage of plugins should be controlled by some mechanism, that only permits certain users, those that you trust, to use the plugins that you feel to be risky.

We've had some discussion around this in the ECA issue queue here: https://www.drupal.org/project/eca/issues/3346710; we didn't come to any conclusion yet, but the GovCMS could be the trigger to get back to this. My personal preference would be to control plugin usage permission on a per-role basis, i.e. utilising Drupal permission system that's already available. That way, we could even control, which roles are permitted to use each plugin while building models and also, which roles are permitted to execute them. That would be easy to implement, but there is one unresolved issue with that: by default, usage of plugins should not be restricted. So, how do we build a good UI for sites that need to restrict plugin access; bearing in mind that we currently already have more than 600 plugins and that installing a new module could unintentionally bring new plugins with it, which would then be enabled, and nobody notices that. Maybe that can be resolved by allowing to configure the default permissions for new plugins on a per-site basis.

Happy to discuss this further, either here or in the linked issue.

[simesy]

Very interesting stuff, thanks!

[TobyWild]

Keeping in mind your analogy of developers who write custom modules having unlimited access, and that people who build ECA models should also have unlimited access.

The problem is that on the GovCMS SaaS platform, (in order to maintain security and stability) there is no custom modules allowed.
And User 1 is blocked on live production sites due to their god-powers.

Providing the ability for users to create a rule that can invoke those powers on live production or unblock that user, would (I'm guessing) be an unacceptable security risk for the GovCMS team.

However, I'm sure even without that specific permission there is still loads of helpful use cases for site builders.

On one hand, I think it would a positive to have the ECA modellers enabled on Prod, so that if, for example, you have a model that sends an email, and that email text needs updating, you can do that via the UI without having to do a code deployment.

On the other, we need to restrict the plugins (and specific configuration of certain plugins) that users can use, which for unblock is easy, we could just disable that plugin via something in the existing GovCMS Security modules.

But for Switch User, which would be very handy to have, the only thing we really want to prevent is it's use in switching to User 1, which would require more than just blocking the plugin.

Which could easily be done if everything was stored in Config, but that would then mean not having access to the modeller on Prod.

Perhaps a form validation alter that prevents certain configurations being saved on the Modeller Save function?

I also agree with Si about having a few standard models setup and disabled as part of the initial install.

[jurgenhaas]

Perhaps a form validation alter that prevents certain configurations being saved on the Modeller Save function?

That's certainly possible. Alternatively, we could offer either an allow-list or a deny-list for user IDs supported or not supported by the switch user plugin. That list should be maintained as a setting in settings.php because config could be altered by ECA models, so that's not safe from being overridden.

We will then have to also adjust the general setting of ECA which allows defining a user who's always being used for ECA processing.

Having said that, maybe that config solves your requirement entirely? You could define a user account which is always used for ECA execution. Then you could maybe completely disable the switch user plugin.

[silverham]

+1 for uses case, it seems reasonable.

[murraywoodman]

This suite modules is general purpose and useful. It is a worthy inclusion to the distro. It will unlock a lot of functionality and creativity and effectively 2x the utility of a GovCMS SaaS site.

[brett-sargeant]

Limited use cases for us, but it would be handy to have things like news items be auto deleted after x time.

[TobyWild]

ECA Overview.pdf

Attached is a pitch document showing a potential implementation plan.
The main problem is that there are a few actions that GovCMS wouldn't want users to be able to trigger, and the BPMN.iO modeller is really user-friendly but it's difficult to restrict, short of auditing all the config yml files, which would require additional development time.

The solution I'm proposing then is to get us over the line and at least get some new functionality, just don't include BPMN.iO modeller in the initial release. Sure the admin interface wont be as nice, but because it's a standard Drupal form, we can write some simple Form Alters to restrict what we don't want available.

Thoughts?

[jurgenhaas]

@TobyWild like the idea you're outlining on how this could be approached. However, I'd suggest not going for the classic modeller. It is really minimally maintained. And later, there is no upgrade path for existing models to be moved over to bpmn.io - it's possible the other way round, but not from cm to bpmn as we don't have anything to build the visual model from.

That said, if a hook (or event) to alter the list of plugins is what unlocks the integration of ECA and BPMN.io, then we could provide that easily for you.