Added override feature for launcher options in Workflow edit page

[harshit-soora]

Epic: #4993
Big discussion under: #5311

• Added option to override or set same values for common fields such as Account, Queues, Hour, Environment Variables, Job Name from the workflow edit page
• This feature is added under advanced options
• Reuses smart_attributes from Launchers for implementation
• Accessibility tested, with latest changes edit page stays accessible
• Unit tests pending, will be handles in a separate PR

[Bubballoo3]

From a UI perspective I think this is great. I do think we need to pick a lane and decide whether these settings are supposed to be set in the workflow edit page, or if you just build a form there that you fill out before each workflow. I lean a bit towards the second option, mostly because it will create a lot of similarity between launchers and workflows with how they handle forms, caching, etc.

That's still an open question that I will discuss with the team today and tomorrow. In the meantime, I noticed a bug where the form interrupts validation on the workflow form, (try submitting a workflow with no launchers selected and an advanced form filled out), and we should definitely test to make sure that caching and overrides are all behaving properly. This is an important thing to get right and we aren't under time pressure for a release so we should absolutely include tests as part of this PR.

[Bubballoo3]

Ok after discussion the second option is the way we want to go. Long term end goal is that workflows share as much launcher functionality as possible (buttons to launch with or without filling out a form, caching, etc).

We won't be able to do all of that here, but I think a good starting point would be making the workflow form a true form builder by adding the form item options that launcher form builder has. So things like fixing values, adding mins/maxes to number fields, all important. We then make it so that it presents the form every time you press submit from the workflow editor. The only way to avoid the form is to use the 'Launch' button on the workflow card, which would use default values (eventually cached) and bring you straight to the workflows UI to watch the progress.

After we get that taken care of, extensions would be:

• detect if a form has any un-fixed value and only show the form if it does. I think a big counterpoint in my mind to showing the form every time is how annoying that would be for something mundane. The issue of account mentioned in Add global/scoped launcher fields #4746 comes to mind, where you wouldn't want to have to select an account each time, or even be presented with a form if you never need to change the workflow-level override.
• implement/reuse the caching system from launchers.

How does that sound for a plan?

[harshit-soora]

Presents the form every time you press submit from the workflow editor

I found this to be a overkill for this feature. I definitely love the idea of Launch on workflow card for quick submit.
Alternative could be to have advanced open under show page (where you draw your workflow). But showing it every-time on submit might be annoying to the user.

[Bubballoo3]

But showing it every-time on submit might be annoying to the user

That's what the fixed attribute detection should solve. This is different from the launcher case in that launchers require forms, while they are optional in workflows. So provided we don't show forms with only fixed value options, then the only reason to set up a non-fixed value form item is if you intend to fill it out every time (or rely on the cache most of the time, but change it occasionally). I think it is more straightforward on all sides to change this behavior based on the form content rather than adding an additional configuration like 'Show form each time?'. The central idea remains the same though. We know that some workflow overrides will be 'set it and forget it' where you want a fixed value that you never set manually, and some configs will have to be set differently on different runs (input parameters, eg). So we just need to find the simplest way to get a clean experience across those different use cases

However the hardest part of this effort IMO is going to be presenting the form in the workflows UI within a modal. Even if it is only enabled through a config, the fact that it will be possible means that we have to implement that piece.

[harshit-soora]

I need you suggestion here:

While advanced feature was best for workflow edit page as per total code foot-print (no redirects, no issue in saving the advanced options to backend), now that I think of show page will be more appropriate as we don't want user to reuse any prior settings and forget about it.

On workflow show page, if we add new advance form for submit, then we will have redirects goto to that new page and coming back on workflow show page (unnecessary maintenance in long term).

What if we keep an advanced submit, just on right side of submit or in drop down to submit button. When you click it, it will move the canvas down and show the advances options. Staying on the same page thus saving redirects! There will be some wiring need to send the advances options to backend and saving those to workflow file. Lmk your thoughts.

[Bubballoo3]

What if we keep an advanced submit, just on right side of submit or in drop down to submit button. When you click it, it will move the canvas down and show the advances options. Staying on the same page thus saving redirects! There will be some wiring need to send the advances options to backend and saving those to workflow file. Lmk your thoughts.

I think that is along the right track, and I agree that a redirect would be quite disruptive in the middle of submission. You should be able to avoid any wiring issues by using turbo frames. That way you can present a ruby form to the user just like launchers, without ever leaving the workflow editor.

In my mind it would be easier to have a popup modal that contains the form, similar to the new file dialog in the files app. But if moving the canvas down and inserting the form above works better, then I am not opposed to that.

I do want to call out though that the redirects question is separate from the question of presenting the form on launch or having an 'advanced submit' button. No matter which button opens the form, it will end up having the same effect. So I would lean towards just keeping a single 'Submit' button and detecting from the form whether it needs to be shown (that is, whether there are any non-fixed values)