Bug 1974180
Summary: | Default user input value is not set for job invocation | ||
---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Hao Chang Yu <hyu> |
Component: | Remote Execution | Assignee: | Adam Ruzicka <aruzicka> |
Status: | CLOSED ERRATA | QA Contact: | Peter Ondrejka <pondrejk> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.9.0 | CC: | aruzicka, lstejska, pondrejk |
Target Milestone: | 6.12.0 | Keywords: | 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
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/31845 has been resolved. 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 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? 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 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 |