1974180 – Default user input value is not set for job invocation

Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1974180 - Default user input value is not set for job invocation

Summary: Default user input value is not set for job invocation

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Satellite
Classification:	Red Hat
Component:	Remote Execution
Sub Component:
Version:	6.9.0
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	medium
Target Milestone:	6.12.0
Assignee:	Adam Ruzicka
QA Contact:	Peter Ondrejka
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2021-06-21 05:04 UTC by Hao Chang Yu
Modified:	2022-11-16 13:32 UTC (History)
CC List:	3 users (show)
Fixed In Version:	rubygem-foreman_remote_execution-7.0.0
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2022-11-16 13:32:43 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Priority	Status	Summary	Last Updated
Foreman Issue Tracker	31845	Normal	Closed	Default values are not set in the job invocation form	2022-05-12 14:26:28 UTC
Red Hat Issue Tracker	SAT-12906	None	None	None	2022-09-13 08:36:56 UTC
Red Hat Product Errata	RHSA-2022:8506	None	None	None	2022-11-16 13:32:52 UTC

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

Note You need to log in before you can comment on or make changes to this bug.