Bug 1974180

Summary: Default user input value is not set for job invocation
Product: Red Hat Satellite Reporter: Hao Chang Yu <hyu>
Component: Remote ExecutionAssignee: Adam Ruzicka <aruzicka>
Status: CLOSED ERRATA QA Contact: Peter Ondrejka <pondrejk>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.9.0CC: aruzicka, lstejska, pondrejk
Target Milestone: 6.12.0Keywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: rubygem-foreman_remote_execution-7.0.0 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-11-16 13:32:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Hao Chang Yu 2021-06-21 05:04:47 UTC
Description of problem:
The default user input value is not set when running a remote execution job.

Steps to Reproduce:
1. Clone the "Run Command - SSH Default"
2. In the "Inputs" tab, uncheck the 'Required' checkbox.
3. and then set a default value to any command, such as 'echo "Hello!"'
4. Run a job with that template without feeling the "command" input box.

Actual results:
No command is run

Expected results:
the default command is run

Additional info:
The issue seems to happen in the following methods.

In 'app/models/input_template_renderer.rb'
  def values_from_invocation
    input_values = @invocation ? Hash[@invocation.input_values.map { |iv| [iv.template_input.name, iv.value] }] : {}
    default_values = template.default_input_values(input_values.keys)  <======== It ignores the input even the value is blank.
    result = @preview ? input_values : default_values.merge(input_values)
    result.with_indifferent_access
  end

In 'app/models/job_template.rb'
  def default_input_values(input_values)
    result = self.template_inputs_with_foreign.select { |ti| !ti.required? && ti.user_template_input? }.map { |ti| ti.name.to_s }
    result -= ignore_keys.map(&:to_s)
    Hash[result.map { |k| [ k, nil ] }]  <========= It ignores the default value we set and just set 'nil' for all default values.
  end

Comment 1 Bryan Kearney 2022-05-03 16:03:49 UTC
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/31845 has been resolved.

Comment 3 Peter Ondrejka 2022-07-13 11:07:18 UTC
Checked on Satellite 6.12 snap 1, the default value is correctly populated on first selection and on reruns, but I find the following behavior confusing:

1. create the cloned ssh template as described above
2. select it in job invocation dialog -- see the command field is populated with the default value
3. change or delete the command manually 
4. select a different template from the *same* job category -- in this case "Run Command - SSH Default", the command field is blanked
5. change back to the cloned template -- the command field is not populated with the default, whatever you have set in step 3 persists

Note that if we select from a different job category in step 4 and then get back to the cloned template, the default is populated as expected

Comment 4 Adam Ruzicka 2022-08-01 11:48:43 UTC
Isn't that a feature? When you change the template, we ask the server for a new form and replace what is currently shown with what the server gives us. If a value of an input field is unchanged, the browser renders the value provided by the server. If a value is changed by the user, the browser remembers it by the name of the element. Then, if a part of the document is replaced, the browser still remembers and uses the user-set values.

To be honest I don't really see a clean solution to this. Once we transition to the job wizard, we will have a greater degree of freedom and will be able to solve it in a non-hacky way (note, it currently does not work as expected).

As I see it, we have three options:
1) Leave it as is
2) Place a "reset to default" button next to the input
3) Add some JS hack so that when the form is being replaced, it walks through all the inputs and resets them to their default values.

@pondrejk Opinions?

Comment 5 Peter Ondrejka 2022-09-13 08:23:51 UTC
I like the option two, possibly with a detection if the default is changed. Let's revisit the discussion when as part of the new UI design in SAT-5770.

The original issue of this bz is fixed ok, checked again in Sat 6.12 snap 10, moving to verified

Comment 9 errata-xmlrpc 2022-11-16 13:32:43 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Satellite 6.12 Release), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:8506