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).