Adding Disable Option for AI Automators

• Added a special "disable" row to the table
• Modified the form rendering to check row positions relative to the disable row
• Added logic to disable fields in rows below it
• Split the form submission into two actions: "Resort" (current behavior) and "Save" (to persist disabled states)
• Added a mechanism to track and persist the disabled state of configurations below the disable row
• Modified the form to include two submit buttons
• Updated the submit handler to handle both actions differently

• "Save" should persist the order and disable rows below the disable line
• On page reload, disabled rows should maintain their state.
• Ensure disabled rows maintain their state after submission

Screenshot retaining the position post save the disabled rows.

The automator was not working when enabled the field once you disable it. Fix added for this issue.

MR updated and pipeline passed.
Please review.

Left comments in MR

Reviewed MR !490. Tested the functionality and disable option is working fine.

I have a concern about re-sort option. Once we disable a field in AI Automator Run Order, On clicking the re-sort the disabled field is enabled and sorted. Shouldn't we only consider enabled fields while re-sorting?

Example scenario: If there is a large number of fields in 'AI Automator Run Order' , user disables one or more fields and needs to re-sort the enabled fields.

@annmarysruthy Yes the resort should not enable disabled fields and resort them. That should be fixed.
Moving the ticket to Needs work.

Tested the changes and Changes look good. Moving to RTBC.

It would also be good to get some reviews from other community members. Changing status to NR.

This applies cleanly as works as described. I'm in two minds about the two separate buttons, though: my gut feeling is that this is confusing UX and if I drag an automator into disabled and click resort instead of save I don't expect the automator I moved to jump back into the active area. However, I'm not sure what could be done about this, or that this expectation would be the same for everyone.

as it stands, this is an improvement and works so possibly we should leave my questions for a future issue and mark this as RBTC again?

@mrdalesmith Can we modify the functionality so that clicking the "Re-sort" button first saves the current state (including enabling/disabling items based on their position relative to the disable row) and then resorts only the enabled items, we can combine the submitFormSave and submitFormResort logic into a single workflow triggered by the "Re-sort" button. This ensures that when you move an item below the disable row and click "Re-sort," the save operation happens first (updating the disabled/enabled states), followed by the re-sorting of enabled items.

I'm not really the person to make the call, but I can see that we do need two separate buttons: some people may wish to reorder the providers, whilst others may want to save the position they have been manually put into by them. I don't think a single button could suit everybody (which maybe why there wasn't originally any functionality to enable/disable the providers from this listing).

Ok lets wait for input from maintainers.

@anjaliprasannan I'd like to test/review the MR but it has fallen quite a bit behind in 3 months…

212 commits behind, 7 commits ahead of the upstream repository.

Can you update the fork in GitLab ?

@bisonbleu you can review now

Sorry about this - but could we update this to 1.2.x? Its a feature and can't go into 1.1.x.

When you are done, could you ping me on Slack (marcus_johansson) so we get this in.

@marcus_johansson I have changed to 1.2.x.

Just tested the latest MR with an Article node where 2 fields are setup with Automators » Automator Worker: Direct

• When the automators are disabled in the UI at admin/structure/types/manage/page/automator_chain, saving the node does NOT trigger them i.e. no call to the LLM are made;
• When the automators are enabled in the UI, saving the node triggers both automators i.e. 2 calls are made to the LLM;

NOTES:

@anjaliprasannan, in #5 you write:

Split the form submission into two actions: "Resort" (current behavior) and "Save" (to persist disabled states)

I don't understand why I would want to «Resort» after just sorting the automators ? Resort suggests to sort again, which does not make sense in the context.

Unless you mean to say «Reset»? Reset | Undo here would suggest resetting the current form to its original saved states, in other words «Cancelling the changes.» If this is your intentions here, then «Cancel» might be a better word. But… «Cancel» also suggests to «Go back».

IMHO, there should be just one Save button i.e. the UX should exactly replicate what we see in Manage form display and Manage display tabs.

So yes and «great work!» this works fine with Automator Worker: Direct.

But unfortunately with the addition of Automator Worker: Field Widget disabling the Automators does not hide the field widget action buttons in the edit form and clicking the buttons will trigger calls to the LLM.

Actually the last item @bisonbleu - I think we will create a follow up issue for. Its outside of the scop for this.

I agree, makes sense.

See ✨ Update Automator Disable option for Worker: Field Widget Active

Setting to RTBC…

More feedback is required about what I wrote in #31, that there should only be a Save button i.e. the UX should exactly replicate what we see in Manage form display and Manage display tabs.

@bisonbleu Have moved the resort and save logic together.

The UI appears to work fine with just the Save button. But event when all automators are disabled, it is still possible to trigger a call to the LLM when clicking the action button.

Drupal 11.2.2
drupal/ai:1.2.x-dev
drupal/ai_agents: 1.1.x-dev

Also seeing this error, thought I'm not sure it is related:

Warning: Undefined array key "button_label" in Drupal\field_widget_actions\FieldWidgetActionBase->getButtonLabel() (line 199 of /var/www/html/web/modules/contrib/ai/modules/field_widget_actions/src/FieldWidgetActionBase.php)

When only one item is present and it is disabled, it cannot be re-enabled through the form. The warning message displayed is: "No enabled instructions to re-sort.". Attaching screen recording for the same. Added a fix to allow re-enabling the item in this edge case.