Add ability to disable actions (tasks) in the UI

Interesting suggestion, thanks @ultimike for bringing this up. Had a couple of thoughts:

• Adding a condition before the action(s), which always results in a FALSE result, could already disable subsequent actions. However, that would be complicated, if prior to the message action there's already a condition applied.
• Since BPMN doesn't seem to provide a disable flag for actions (or tasks as they call it), we would have to add a checkbox explicitly by Drupal config forms. Then the follow-up question comes up, whether such a disable flag should only be added to the message actions or all action plugins. The latter could easily be overwhelming.

This leads to the idea, since you're raising this in the context of "debugging", if it wouldn't be a better idea to introduce a new "Debug" action, which displays a message to the user on screen, but we could provide a setting in the ECA config form, which enables or disables all those action plugins site-wide. That way, you wouldn't have to go through all your models to disable each of the messages one by one. A single setting would turn them on or off.

Actually, the same could already be achieved with a custom event: instead of using the message action, you could trigger a custom event and provide the displayed message as an argument. After the custom event, you then use the message action, so that you get the same result. However, here you could put your extra condition between the custom event and the message action to turn this on or off with a single change.

What do you think?

Oooooo - I like this idea:

if it wouldn't be a better idea to introduce a new "Debug" action, which displays a message to the user on screen, but we could provide a setting in the ECA config form, which enables or disables all those action plugins site-wide.

-mike

It might be overwhelming, when you enable them, if you have many debug messages. I like the debug message function, but maybe a checkbox on each one to enable, and a button to disable all. Maybe as an option on a "save" dialog, to remind you to disable when you save the setup.

If you store the desire to show / hide debug messages in the Drupal State, it never leaves the current site. Maybe you could even put a link at the bottom of any ECA-generated Debug messages to go to the admin screen to "turn off these debugging messages".

Would like to come back to this suggestion:

Actually, the same could already be achieved with a custom event: instead of using the message action, you could trigger a custom event and provide the displayed message as an argument. After the custom event, you then use the message action, so that you get the same result. However, here you could put your extra condition between the custom event and the message action to turn this on or off with a single change.

The attached model bpmn_io-debug.tar.gz contains that custom event, a condition and the display message action. It can be imported into any Drupal site with no side-effect. It looks like this:

Once that's available in a Drupal site, you can call debug messages like this:

In the Set message action, you set the debug_message token and then call the debug custom event by forwarding that token, which will then be displayed.

With this in place, you only have to change the condition in the debug model to turn all debug messages on or off.

The beauty of this approach, at least in my view:

• You have the option to add to the debug model to undertake even more actions when the debug event is being called, e.g. also write a message to the logs or even send an email to the administrator.
• The condition can be turned into something more sophisticated, e.g. depending on some other context deciding if and when or how a debug message will be displayed.

To me, this seems to be the more powerful solution as it can be customized, more than any action plugin could ever be.

This is a cool idea. Let me test it out with some of my students and get back to you.

Thanks!

-mike

We took some time to play with this method during DrupalEasy office hours today, and we were able to reproduce what @jurgen suggested (without importing his model 😃).

This is a pretty good solution, most of our conversation revolved around where to put the "kill switch" for outputting the debugging messages. We discussed three possibilities:

1. Global: Put the kill switch in the "Debug messages" model - this would enable/disable the output of debug messages for all models on the site.
2. Per-model: Add the kill switch value as a token in each model, then pass along that token to the "Debug messages" model.
3. Per-message: Add the kill switch value as a token immediately before each debug message "set token" action.

Personally, I think I'll be using the "Global" method, but I can see the benefits of the other methods as well.

thanks!
-mike

Thanks a lot @ultimike for your detailed feedback.

As for the kill-switch, those different approaches could even be mixed, I guess.

This whole topic should be documented or at least be written down in a tutorial or a blog post. Any chance that you could get something together with your students for this?

Sure, we can do that. Care to suggest the best place in https://ecaguide.org to add it to?

-mike

@ultimike there is the existing [Debugging](https://ecaguide.org/eca/debugging/) page, this is probably where users would search for this kind of information? At least from a documentation perspective.

If it were more like a tutorial, then I'd suggest https://ecaguide.org/resources/