allow users to change cluster dropdown in the form yml

[johrstrom]

Fixes #532

• users can change the order (the cluster is usually first) by
  specifying cluster in the form
• if attributes are specified the bc app now respects that config
  but does not do any validation

[ericfranz]

So this assumes that cluster: is still specified at the top of the document, and cluster: is specified somewhere in the attributes list.

Maybe I need to produce some examples, but I was thinking it would be preferable to have the freedom to be able to omit cluster: completely from the form.yml and then with a mixture of the form.yml and form.js ensure that the submitted web form eventually specifies cluster: OR the submit.yml eventually specifies cluster. So that the error would be reported after handling the user's form submission and right before attempting to submit the job, that no cluster was specified - instead of when you visit the web form.

Here is an example.

For our future uber batch connect app, one approach to implementing it would be a dropdown chosing Owens, Pitzer, or Ruby, and a radio box to choose "Shared VDI" or "Dedicated Hardware". Now the cluster would be Quick if the radio box was Shared VDI, but if the radio box was "Dedicated Hardware" the cluster would be Owens or Pitzer or Ruby.

In this case I'd imagine we would do one of two things.

1. Write some JavaScript in the form.js to try to update the value of a hidden cluster input field based on the form selection
2. In the submit.yml.erb, choose the cluster based on the form options provided.

I might prefer to write Ruby instead of JavaScript in this case and choose the latter. If I chose the former, can I specify cluster as a hidden attribute in the batch connect app? If so, then this PR would support this change.

Though I'd say that in this case it would seem superfluous to have to specify at the top of the form cluster: [ owens, pitzer, ruby, quick ] and its those type of duplicate steps (like having to put a new form element in both the attributes and form section) that trip people up.

[johrstrom]

Updated. Validity still requires either cluster be defined (and valid) or form.cluster (which has no validation). This enables, from your use cases listed, number 1 and the more simple cases of just defining the cluster through form.cluster and attributes.cluster without js modification.

I don't believe 1 and 2 are mutually exclusive, but if enabling number 2 we'd lose a lot of validity checks. Either way, it could be discussed in #529.

[ericfranz]

So validity serves two purposes right now.

1. Authorization. If we deploy a Ruby only app and you do not have access to Ruby, the cluster acl ensures job_allow? returns false and then that cluster is excluded, so the app is not valid?
   • We want to get rid of this eventually. Instead, authorization should be enforced using file permissions for the app, and the app title should be pulled from the manifest file. The form.yml.erb should not be rendered when creating the menu.
2. Display an error if you access the page directly anyways, saying no valid cluster is configured. Users won't be able to access this except through the developer interface, or inserting the URL manually.
   • This is duplication of the error we can display to the user after the user submits the web form - we of course would want to handle this gracefully if code has not been added yet to handle that - it would be after submit.yml is processed but before the job submission occurs.