Bug 1120657

Summary: Adding two OS parameters with same name doesn't raise any error when values are different
Product: Red Hat Satellite Reporter: Sachin Ghai <sghai>
Component: WebUIAssignee: orabin
Status: CLOSED ERRATA QA Contact: jcallaha
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.0.4CC: bbuckingham, cwelton, sthirugn
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
URL: http://projects.theforeman.org/issues/6695
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-12 05:10:29 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:
Bug Depends On:    
Bug Blocks: 1123360    
Attachments:
Description Flags
can add two params with same name but having diff values.
none
Name already taken raises only when parameters values should be same along with names none

Description Sachin Ghai 2014-07-17 11:25:12 UTC
Created attachment 918677 [details]
can add two params with same name but having diff values.

Description of problem:
I was trying to perform some boundary tests on OS parameters. I defined OS parameter say release_ver with value 2.6.14
I defined same parameter again with value 2.6.16

Both parameters were created successfully. Please see the screenshot.

However when I defined release_ver two times with same values, then on submit, the page moves to 'operating System' tab instead of 'Parameters' tab. 


Version-Release number of selected component (if applicable):
Sat6 GA snap0

How reproducible:
always

Steps to Reproduce:
1. create OS and following parameters
a) release_ver with value 2.6.14
b) release_ver with value 2.6.16

2. OS should be created with above parameters.
3. Now update the first parameter b) release_ver with value 2.6.14 from 2.16.16
4. UI switched to other tab, Now UI raises error 'Name already taken" but switched to other tab 

Actual results:
There are two issues:
1. when parameters name are same but values are different then UI doesn't raise any error
2. when parameter name as well as value are same then UI raises error but quickly switch to other tab and error remains under 'Parameters' tab

Expected results:
1. when parameters name are same but values are different, still UI raise error like Validation Error: Name already taken
2. when parameter name as well as value are same then UI shouldn't switch the tab, it should stay on 'Parameters' tab

Additional info:

Comment 1 Sachin Ghai 2014-07-17 11:26:17 UTC
Created attachment 918678 [details]
Name already taken raises only when parameters values should be same along with names

Comment 2 Sachin Ghai 2014-07-17 11:31:50 UTC
OK, for Issue 2).. I'll open a separate issue. Since its failing for other input values too.

Comment 3 Sachin Ghai 2014-07-17 11:43:17 UTC
For issue2, bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1120657

Comment 5 orabin 2014-07-20 05:50:27 UTC
Created redmine issue http://projects.theforeman.org/issues/6695 from this bug

Comment 6 Bryan Kearney 2014-09-23 12:03:26 UTC
Moving to POST since upstream bug http://projects.theforeman.org/issues/6695 has been closed
-------------
Ori Rabin
Applied in changeset commit:998e1438d28786165f41c9a1d76c29e3b759fcf3.

Comment 7 jcallaha 2014-10-10 19:35:18 UTC
*** This bug is verified in upstream.  This fix should eventually land in future downstream builds ***

Verified in RHEL6/RHEL7

* candlepin-0.9.32-1.el7.noarch
* candlepin-common-1.0.8-1.el7.noarch
* candlepin-selinux-0.9.32-1.el7.noarch
* candlepin-tomcat-0.9.32-1.el7.noarch
* elasticsearch-0.90.10-7.el7.noarch
* foreman-1.7.0-0.develop.201410091913git35b6fb9.el7.noarch
* foreman-compute-1.7.0-0.develop.201410091913git35b6fb9.el7.noarch
* foreman-gce-1.7.0-0.develop.201410091913git35b6fb9.el7.noarch
* foreman-libvirt-1.7.0-0.develop.201410091913git35b6fb9.el7.noarch
* foreman-ovirt-1.7.0-0.develop.201410091913git35b6fb9.el7.noarch
* foreman-postgresql-1.7.0-0.develop.201410091913git35b6fb9.el7.noarch
* foreman-proxy-1.7.0-0.develop.201410081229git52f0bac.el7.noarch
* foreman-release-1.7.0-0.develop.201410091913git35b6fb9.el7.noarch
* foreman-selinux-1.7.0-0.develop.201409301113git2f345de.el7.noarch
* foreman-vmware-1.7.0-0.develop.201410091913git35b6fb9.el7.noarch
* katello-2.1.0-1.201410091752gitc9c45c1.el7.noarch
* katello-certs-tools-2.0.1-1.el7.noarch
* katello-default-ca-1.0-1.noarch
* katello-installer-2.1.0-1.201410021645git304e036.el7.noarch
* katello-repos-2.1.1-1.el7.noarch
* katello-server-ca-1.0-1.noarch
* openldap-2.4.39-3.el7.x86_64
* pulp-docker-plugins-0.2.1-0.2.beta.el7.noarch
* pulp-katello-0.3-3.el7.noarch
* pulp-nodes-common-2.5.0-0.7.beta.el7.noarch
* pulp-nodes-parent-2.5.0-0.7.beta.el7.noarch
* pulp-puppet-plugins-2.5.0-0.7.beta.el7.noarch
* pulp-puppet-tools-2.5.0-0.7.beta.el7.noarch
* pulp-rpm-plugins-2.5.0-0.7.beta.el7.noarch
* pulp-selinux-2.5.0-0.7.beta.el7.noarch
* pulp-server-2.5.0-0.7.beta.el7.noarch
* python-ldap-2.4.6-6.el7.x86_64
* ruby193-rubygem-ldap_fluff-0.3.1-1.el7.noarch
* ruby193-rubygem-net-ldap-0.3.1-2.el7.noarch
* ruby193-rubygem-runcible-1.2.0-1.el7.noarch
* rubygem-hammer_cli-0.1.3-1.201409240954gitf3c47c7.el7.noarch
* rubygem-hammer_cli_foreman-0.1.3-1.201409191432gitc38f9c8.el7.noarch
* rubygem-hammer_cli_foreman_tasks-0.0.3-2.201409091410git163c264.git.0.988ca80.el7.noarch
* rubygem-hammer_cli_import-0.10.4-1.el7.noarch
* rubygem-hammer_cli_katello-0.0.6-1.201410091836gitf7ca881.git.0.4d3b99d.el7.noarch

Comment 8 Bryan Kearney 2015-08-11 13:31:13 UTC
This bug is slated to be released with Satellite 6.1.

Comment 9 errata-xmlrpc 2015-08-12 05:10:29 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, 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-2015:1592