Create recipe for certain technical redirects with ECA

This MR contains an ECA model which does several redirects:

• On a 403, it redirects to the login form and later forwards to the original destination
• On login, it redirects to the dashboard
• On logout, it redirects to the login form

Changing those redirect destination in the model is a simple task and if we decide on different ones, this can be updated.

Tests will follow when the model as such is what we actually want.

Dashboard is wrestling with a redirect issue right now: 🐛 Dashboard should not force redirect on password reset or override other redirects Active

This seems like a possible way around that? I think it might make sense to not have the module force it, even once the password reset instance is fixed.

But I also feel like this one just needs tech review, since from a user perspective there's no difference what is doing the redirecting.

Over to @phenaproxima and @tim.plunkett

Well, if we're okay with using ECA as the redirect engine, then I don't have any particular problem with that on the technical level.

My concerns at this juncture are:

• ECA is, frankly, extremely hard to grok. I don't fully understand it myself. The config entities are indecipherable walls of XML. If power users or even developers want to change this configuration, will the use of ECA scare them off? This is probably more of a documentation issue than anything, so I guess my question is -- what's the status of ECA's documentation? I'd love to get the track leads of the documentation track to weigh in on this. If the documentation isn't up to snuff, that wouldn't necessarily block commit, but I think getting proper documentation for it would be a potential release blocker.
• Tests aren't passing in HEAD. Let's get that fixed.
• We definitely will want dedicated test coverage of all the redirects we're providing here. This should be a dedicated functional test that lives in the recipe which provides these configurations.

ECA is, frankly, extremely hard to grok. I don't fully understand it myself.

Very much same. I guess though in the case of the 403, we have to weigh that against the fact that r4032login doesn't have a D11 version yet, and there is a fair bit going on in that module too. What's harder to understand? Depends where you are coming from I guess.

I really don't have a strong opinion on this either way, because I can see pros and cons on both sides, so happy to leave it up to you.

I'm looking into the failing tests, it seems that ECA redirects to /admin/dashboard/welcome where the test expects /admin/dashboard. That should be simple. I'll also address the additional tests for the scope of this recipe.

Regarding "ECA is, frankly, extremely hard to grok." there are several points here:

What's interesting, that we have hundreds of users, a lot of them not being developers, who are thrilled with what they can do with ECA, and they are far less scared than I would have anticipated.

The config entities are indecipherable walls of XML

ECA comes with a pair of config entities for each model. The eca.eca.ID config entity is very lean and does NOT contain any XML. That's what really matters and is used by ECA. The second one is eca.model.ID and contains the XML for the modeller. It contains the XML format for that modeller who needs to know which object is positioned where in the canvas. That's the only purpose for it and we don't need to worry about that. Note: the ECA team discussed at the beginning of the ECA development 3 years ago, if this modellers data should be stored elsewhere. But we went for a separate config entity for it, since that keeps the deployment of ECA models easy, as we can utilizes Drupal core's CMI.

So, if power users or even developers want to change this configuration, will the use of ECA scare them off?

Our experience is just the opposite, see above.

This is probably more of a documentation issue than anything, so I guess my question is -- what's the status of ECA's documentation?

ECA is very well documented, see https://ecaguide.org - users call it one of the most comprehensive documentations in Drupal's contrib space.

Unassigning from myself while awaiting dedicated test coverage. :)

I offered to write the tests here in the name of accelerating this MR, so self-assigning for that.

That wasn't too hard. Dedicated tests are now added.

Nice, thank you so much @phenaproxima for the tests and the review. I've commented on all the threads. A few of them need a decision, and I'll be happy to work on the required changes then.

We now have very strong test coverage here (yay!) and I don't think I have anything else to complain about. Since Jim has started reviewing this, I'll leave the RTBC up to him. But I'm comfortable committing this.

Marking as RTBC, although the merge request is in Draft mode and will need to be changed before it can be merged.

By adding ECA in Drupal CMS, this provides a great foundation for other no-code development and workflows.

Yeah, I've removed the draft flag and rebased the MR. Should be ready to go. Thank you @phenaproxima and @thejimbirch for working on this and helping to move this forward.

By adding ECA in Drupal CMS, this provides a great foundation for other no-code development and workflows.

Couldn't agree more :-)

Great collaboration on this, and it's nice to have these very sensible redirects implemented with strong test coverage. Merged with glee and gratitude into 0.x. Thanks!

Automatically closed - issue fixed for 2 weeks with no activity.