Add UI/UX to add multiple automators on a field

Switching to the correct tag

Add skill tags for issue discovery

I think this form is actually the wrong spot for these, the field form is for the field config (i.e. field.field.node.article.field_image.yml), however, Automators are their own config entity (i.e. ai_automators.ai_automator.node.article.field_image.default.yml)

There is technically already an admin interface here at /admin/config/ai/ai-automators/ai-automator:

→

Why not utilize this to handle automators and just link to it from the field config form? Given the idea seems to be to allow multiple automators on a field instance, you could also set this up similar to image styles in which each automator chain from the next using weight to determine order?

I'm envisioning something like this, where you would first pick your entity type and field, once saved the entity/field cannot be changed, only deleted, but then the automators become available based on the field type, as many as you want can be added and changed, also allowing the result to provide context to the next in line:

→

Thoughts?

I like the suggestion. The first screenshot is nasty-long. As well as separating out the automators, a simple link from file Operations would be good.

Ok, I'm going to start down this route and see if any snags appear

Another idea, maybe this deserves its own tab on field edit page? Like a separate page "Automators" with its own link that can also go into operations dropdown?

@a.dmitriiev I like that, I will add after the refactor on the plugins, this is a big ol rat's nest with the automators vs automator types

I do think having the simple option to describe how to fill out a field via AI on the field configuration form is good UX/UI - based on working with three different F500 companies, this was the only way we could enable them to work with chainable AI and understand how the field configuration connected to how the AI generated the field.

They had none-developer domain specialists from their companies sitting and setting this up for them and got it working. However the only thing we did compare to was Field UI + ECA, that is a lot more complex.

I do like the new ux from @b_sharpe, it reminds me of how Field Validation module does work, which is easy once you understand the workflow.

There is an reordering page/tab already - it might make sense to add the add button there, see screenshot:

→

My own personal preference would be to use the form called out in #10 as the place where Automators are defined. Then, the field widget is the only place they need to be associated with a particular field (since the action elements are currently only for forms). Maybe the widget configuration piece could allow an Automator to be defined in the settings tray or in a modal?

I think it makes sense for Automators to be able to share configuration between fields, as this will may it easy for the same element to work in the same way in different places on the site. If a different field needs an automator to work in a different way, we should allow Automators to be easily cloned.

MR is there now, haven't looked at failures on tests yet. Will post a quick video tomorrow to show changes. Something with field widget actions is also broken so not sure if we want to deal with that here or in another issue

• Update Hook fixed
• Added BC for field_action_widgets
• Tests Fixed

Ready for a review, Here's a summary of changes and a walkthrough:

1. Moved AutomatorType to proper configurable plugins
2. Update AiAutomator Add/Edit form to allow multiple automatorTypes per instance
3. Update processing of automators to use plugins and process by weight of both automators and automator types
4. Removed Add/Edit from initial Field Creation, but added options after create
5. Only allow field widget actions on automators with 1 automator type (future features?)
6. Updated Chain form to support multiple automator types

Walkthrough Video: https://www.drupal.org/files/issues/2025-08-26/multiple-automators.mp4 →

Nice video walkthrough - very helpful.

I know I was the first to suggest the option was added to the Operations drop down - and I like that it's there - but the 'AI Automator Run Order' tab now feels a bit weird. I haven't tried this myself, but can you also add new operators from that tab? I'm just thinking of how intuitive this interface would be for both seasoned and new Drupal admins, i.e. does it match other similar admin UIs such that it's consistent and intuitive. That feels a little like the Views UI where you can add a field to a View and then 'Arrange' the fields via another button.

As long as users can get to the options they need, having multiple ways of doing this doesn't seem like a problem to me. Nice work.

Thank you @bryan - I have done the test and an initial code review to split it down in different parts:

UX/UI and manual testing:

I believe this is really much better then what we have now and it opens up the possibility for actually using multiple Automators everywhere, which in its turn with Field Widget Action will allow for doing a lot of processes that the Automator can't do by itself.

There are minor issues I can see that could be fixed, or discussed in follow up issues, like the breadcrumbs when adding Automators should probably have the content type you are adding at the moment somewhere in there. They are very minor to me.

Functionality

I thought about the grouping that is happening now with a parent weight and custom weight and if this will be an issue. But I haven't been able to think of a realistic use case where this is an actual problem, but it would be something like this:

1. Create an image in image field A.
2. Create a description on text field B based on the Image field A.
3. Create an image alt text on image field A using text field B as context.

A use case that does exist realistically though, is to be able to have two rules on a field with different processors. Say that you for instance have a Text with Summary field and you:

1. Want to fill out the field text value via a long running process and use a Queue Worker. Something like scraping that takes some time.
2. Then want to be in control of creating the summary using Field Widget Actions.

So its the same field, but with different workers.

I think this might be UX, rather then having to change any functionality, since you can still have two different configs in

Code review/breaking changes

So there is one breaking change, that I do not see that we can do anything about, and that is the change in the modify method in the AiAutomatorFieldProcessInterface. I think this is a minor issue though, as we know of the only external contrib module that adds a new processing interface and have control to change it and target 1.2.x. This goes against BC in minor versions though, so if we can add this change in 2.0.0 it would be better.

The bigger issue is that there are external modules and privately built modules that exposes Automator Types - the refactoring of using buildConfigurationForm instead of extraFormFields is a breaking change that is to big for a minor version and will break existing sites.

So we have two things we can do there I think:

1. If we already want the change in 1.2.x, we could have in base classes that buildConfigurationForm calls extraFormFields. Then we can set a deprecated on extraFormFields.
2. We wait and use this in 2.0.0 release, that is the next major release and also fix other crappy code in there, since we can do breaking changes.

I haven't gone into details in the review yet, but I wanted to raise this early, so we take a decision there - I am pretty sure that the #1 will work, but since 1.2.0 is soon coming, we might target 2.0.0 instead, since very few features will be added for 1.2.0 anyway?

@marcus_johansson I have no real opinion on if 1.2 or 2.x, I see pros/cons of each. If 1.2 I think it could easily be refactored to just have the old methods call the new and have deprecation notices where applicable. Ideally RulesBase would become AutomatorTypeBase too as it's super confusing having this separate but I think that would have to be 2.x

There are minor issues I can see that could be fixed, or discussed in follow up issues, like the breadcrumbs when adding Automators should probably have the content type you are adding at the moment somewhere in there. They are very minor to me.

I did look at this, and it could be done in a "Tab" per #14, which would essentially just be a pre-filtered list of automators per bundle and would support breadcrumbing, seemed like a new issue to me.

A use case that does exist realistically though, is to be able to have two rules on a field with different processors

This is actually fully working, but a UX issue as you mentioned, you can have multiple automators per field, each with multiple automator types, they are separate entities and process just fine in my testing; however, the UI gets messy since when you "Edit" an automator for a field it now could have multiple items, so I left it out of this, but built the processing so it would work in the future.

The bigger issue is that there are external modules and privately built modules that exposes Automator Types - the refactoring of using buildConfigurationForm instead of extraFormFields is a breaking change that is to big for a minor version and will break existing sites.

Fully agree. If the consensus here is 1.2 I can work on this.

Having watched the video in #21 by @b_sharpe, it makes it quite clear and easy to set up multiple Automators. I am not sure if a non-technical person will easily understand the UI/UX behind it, but I imagine that they would be accompanied by some training prior to better understand the setup.

If we can get this in for 1.2.x then wouldn't that make the demos for DrupalCon Vienna look better for marketing purposes?

I have tried the MR functionality locally and found one thing that I guess will be confusing. It seems that "Automator Worker" is set globally per field still and when more automator types are added they are still using the same "Automator Worker". I think it makes sense to allow each automator type to use different Worker, as for example you can create an automator for field widget actions, but at the same time different automator for cron job, but on the same field. Or am I over complicating things?

Regarding 1.2 vs 2.0, I would like to see this in 1.2 of course, as in combination with Field Widget Actions, this feature will be most valuable now. Maybe it is still just possible to have the old methods (that of course should be marked as deprecated) that will trigger the new methods?