Add a seach input filter to ECA's admin list

This is a nice idea. Not a simple one for implementation, but I can certainly see how this would be very useful.

We also discussed this at the Drupal Dev Days in Vienna 2023, the manually sorted list in the management view is responsible for the order of execution, so this kind of makes sense. However, the order should be only relevant per event type, where it's going to be validated and sorted.

Also see https://ecaguide.org/eca/usage/#admin-ui

With the recent development of event specific execution, it would be helpful to see the execution of rules per event type and not all at once. A filter would be certainly helpful, but maybe we should consider a dedicated view of execution order and not mix it up with the management view, where we could handle a multitude of rules.

To get started with I would appreciate:
- a text-filter for "Model" names
- a multi-select-filter for available "Events"
- a bool-filter for "enabled"

Furthermore, with a fresh and empty installation no list is shown, but we can see the save button. It's not really a bug, but just not necessary when there are no rules to be drag & dropped.

A pager might become handy, when we have more than 50 rules. But a pager would break the sorting feature, which would be another argument to specify the execution order per event and not in the management view. In this case a simple counter behind the listed event could indicate how many rules are using the same event, e.g.:

- Update content entity (Content: - any- )
- Presave content entity (Content: - any- ) [Used by 2 rules]

Clicking on the "[Used by 2 rules]", could bring up a screen where we order the rules accordingly.

Keep up the great work, it's already very useful!

Coming from ✨ Allow model listing page to be filtered Closed: duplicate , I have a working solution based on the Module/Views javascript-based filter.

I'll start an MR shortly.

This is amazing, thanks a lot for your contribution @ergonlogic - I've tested this, and it works really nice. OK, for now it only filters on model name, events and versions, but we can probably build on top of this to address the other features discussed above as well.

The issue fork got re-based for the 2.0.x branch and tests are still passing, which is great.

We have 2 options now: either we merge this into 2.0.x and back port to 1.1.x and address more features later, or we elaborate first, how many more of the requested features can also be addressed by this technique. In the meantime, this is RTBC to me.

I've now merged this into 2.0.x and will back port to 1.1.x tomorrow. If anybody needs more features later, we can then address them in separate issues. Thank you again @ergonlogic for this amazing contribution.

This is now backported to 1.1.x

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