Bug 1013703

Summary: Products can be created with duplicate names, no indication of what provider
Product: Red Hat Satellite Reporter: Kedar Bidarkar <kbidarka>
Component: WebUIAssignee: Justin Sherrill <jsherril>
Status: CLOSED CURRENTRELEASE QA Contact: Kedar Bidarkar <kbidarka>
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.0.2CC: cwelton, ehelms, gkhachik, jmontleo, kbidarka, omaciel
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
the msg when products are unique none

Description Kedar Bidarkar 2013-09-30 15:49:31 UTC 
Description of problem:
When two products with same name, but under different providers exists, No way to find which provider a product belongs to when choosing via existing product under the Repo discovery section.


Version-Release number of selected component (if applicable):
Satellite-6.0.2-RHEL-6-20130925.0

How reproducible:

In as scenario, where there are 2 products with same name, but under two different providers and when creating repo via repo-discovery and choosing Existing Products.

Steps to Reproduce:
1.
2.
3.

Actual results:
Currently no way to know, as to which provider a product belongs to.

Expected results:
There should be a way to find as to which provider a product belongs to.

Additional info:
Comment 2 Justin Sherrill 2013-10-08 21:10:16 UTC 
Kedar, our UI currently does not handle multiple products with the same name very well at all.  We do not list the provider with the product on most any other screen (content search, content views, etc..)  I would be more in favor of requiring unique product names for custom products, do you agree?
Comment 3 Kedar Bidarkar 2013-10-17 10:15:12 UTC 
I think in that case we need to disable creating 2 product's with same names from both UI and CLI.
Comment 4 Justin Sherrill 2013-10-17 15:08:07 UTC 
+1 to that, working on this now.
Comment 5 Og Maciel 2013-10-17 15:54:13 UTC 
Though this would resolve this current BZ, I don't necessarily agree with it. Labels are unique but names don't have to be. The UI could expose another field which the automation could then use to check for the specific item imho
Comment 6 Justin Sherrill 2013-10-17 16:01:44 UTC 
Og,  whats your reasoning for why name shouldn't be unique?  Why would a user want 2 products with the same name?
Comment 7 Justin Sherrill 2013-10-17 17:46:49 UTC 
Og, also to really truly support this, we would need to show some sort of identifying information everywhere we show products.   To me 2 products with the same name in the same org simply does not make sense.
Comment 8 Justin Sherrill 2013-10-17 17:51:16 UTC 
to clarify, we are proposing it to be unique per org
Comment 9 Og Maciel 2013-10-17 17:52:03 UTC 
Talked to Justin and I misunderstood comment #2. Name uniqueness per Org makes perfect sense.
Comment 10 Garik Khachikyan 2013-10-18 07:30:13 UTC 
Please: make the fix for CLI side as well (disabling creation of product with the same name within scopes of one org? I believe).

thanks.
Comment 11 Justin Sherrill 2013-10-18 20:03:18 UTC 
https://github.com/Katello/katello/pull/3216
Comment 12 Justin Sherrill 2013-10-21 13:14:05 UTC 
Commit no longer allows custom product names to be duplicated within an organization.  Red hat products are not affected.  Tested with cli and UI.
Comment 15 Kedar Bidarkar 2013-10-22 10:34:27 UTC 
Created attachment 814927 [details]
the msg when products are unique
Comment 16 Kedar Bidarkar 2013-10-22 10:36:02 UTC 
Attached the msg pic above, stands VERIFIED with 
Satellite-6.0.2-RHEL-6-20131021.0.
Comment 17 Bryan Kearney 2014-04-24 17:11:02 UTC 
This was verified and delivered with MDP2. Closing it out.
Comment 18 Bryan Kearney 2014-04-24 17:12:03 UTC 
This was delivered and verified with MDP2. Closing the bug.