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 859981 (katello-craptastic) - Systems > $system > Content > Packages: I shouldn't be able to enter non-existent/broken package group names
Summary: Systems > $system > Content > Packages: I shouldn't be able to enter non-exis...
Keywords:
Status: CLOSED WONTFIX
Alias: katello-craptastic
Product: Red Hat Satellite
Classification: Red Hat
Component: WebUI
Version: 6.0.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: Unspecified
Assignee: Brad Buckingham
QA Contact: Corey Welton
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-24 14:38 UTC by Corey Welton
Modified: 2014-03-18 17:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-18 17:37:51 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
screenshot (17.76 KB, image/png)
2012-09-24 14:39 UTC, Corey Welton 		no flags Details
View All

Description Corey Welton 2012-09-24 14:38:47 UTC 
Description of problem:
User can enter totally non-existent package group names, including some with wildcard characters or other funkiness, and the UI blindly accepts them.

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


How reproducible:


Steps to Reproduce:
1.  Register a system; sync/promote appropriate content
2.  Systems > $system > Content > Packages
3.  Select the package groups radio button
4.  Enter the string "Craptastic*" in the field and +Add
  
Actual results:
Bogus package group is added - or at least attempted. It appears in the UI

Expected results:
We should be validating data entered into this field. Really, this field should probably be much more integrated with the rest of the search system implemented elsewhere in the UI.


Additional info:
Comment 1 Corey Welton 2012-09-24 14:39:49 UTC 
Created attachment 616593 [details]
screenshot
Comment 3 Corey Welton 2012-10-10 14:02:30 UTC 
Marking as a blocker to for triage consideration
Comment 4 Mike McCune 2012-10-10 14:53:23 UTC 
not severe enough for blocker+, 2.0
Comment 5 Brad Buckingham 2012-10-10 15:16:00 UTC 
This particular issue is a bit more complicated to support than it might appear.  On the packages pane, the user may use the input box to perform Add or Remove of packages; therefore, what is valid actually depends on the action being performed.  For Add, it would a be any package that is available to the consumer (this could be content that is managed by Katello/Pulp or even other repos known only to the consumer).  For Remove, it would be a package that exists on the consumer.

Ideally we could leverage Pulp with it's knowledge of the consumer, the consumer's profile and the repositories bound to it.  At this time, however, there isn't an API in Pulp v1 or v2 available to determine what might be valid for the consumer.  

I raised this briefly with the Pulp team in irc.  Based on the initial feedback, they actually wanted to support something like this in Pulp v2; however, due to how yum works and the fact that the consumer could be using non-pulp repositories, they cannot really determine what is valid; therefore, the decision was made not to support it.

If we want to enforce that a user may only perform these actions for content that is managed by Katello/Pulp, we could probably revisit this with the Pulp team.  Alternatively, we could attempt to derive what is valid from Katello using the information currently available in Pulp; however, that would likely be a more complicated solution.
Comment 6 Mike McCune 2013-08-16 18:22:06 UTC 
getting rid of 6.0.0 version since that doesn't exist
Comment 7 Mike McCune 2014-03-18 17:37:51 UTC 
This bug was closed because of a lack of activity.  If you feel this bug should be reconsidered for attention please feel free to re-open the bug with a comment stating why it should be reconsidered.
Note You need to log in before you can comment on or make changes to this bug.