Bug 859981 - (katello-craptastic) Systems > $system > Content > Packages: I shouldn't be able to enter non-existent/broken package group names
Systems > $system > Content > Packages: I shouldn't be able to enter non-exis...
Status: CLOSED WONTFIX
Product: Red Hat Satellite 6
Classification: Red Hat
Component: WebUI (Show other bugs)
6.0.1
Unspecified Unspecified
unspecified Severity unspecified (vote)
: Unspecified
: --
Assigned To: Brad Buckingham
Corey Welton
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-24 10:38 EDT by Corey Welton
Modified: 2014-03-18 13:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-18 13:37:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Corey Welton 2012-09-24 10:38:47 EDT
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 10:39:49 EDT
Created attachment 616593 [details]
screenshot
Comment 3 Corey Welton 2012-10-10 10:02:30 EDT
Marking as a blocker to for triage consideration
Comment 4 Mike McCune 2012-10-10 10:53:23 EDT
not severe enough for blocker+, 2.0
Comment 5 Brad Buckingham 2012-10-10 11:16:00 EDT
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 14:22:06 EDT
getting rid of 6.0.0 version since that doesn't exist
Comment 7 Mike McCune 2014-03-18 13:37:51 EDT
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.