Bug 839772
| Summary: | Update service level and release of "" to be "Not Set" in Settings Dialog | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Matt Reid <mreid> | ||||||
| Component: | subscription-manager | Assignee: | Shwetha Kallesh <skallesh> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Entitlement Bugs <entitlement-bugs> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 6.4 | CC: | alikins, awood, bkearney, jmolet, jsefler | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | 6.4 | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | subscription-manager-1.1.11-1 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2013-02-21 08:55:24 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: | 771481, 840993 | ||||||||
| Attachments: |
|
||||||||
|
Description
Matt Reid
2012-07-12 19:17:11 UTC
Created attachment 597884 [details]
Blank Strings
(In reply to comment #0) > I'd love to see the empty string replaced with "Not Set". "" vs "None" isn't > a very obvious difference. I think having an actual string would be a big > help here. "None" happens to be a real valid service level for the credentials under which you are currently registered. The blank field which defaults at the top of the gui drop-down list already means not set... [root@rhsm-accept-rhel6 ~]# subscription-manager service-level Service level preference not set which is also consistent with the setting of service level to ""... [root@rhsm-accept-rhel6 ~]# subscription-manager service-level --set "" Service level preference has been unset See related bug 857918 My concern here is that if I looked at that dialog without an intricate knowledge of our service levels and subscriptions, and wanted to ensure I wasn't enforcing a service level preference, what should I select? Should I select Service Level Preference: None? Should I select Service Level Preference: ""? I could see someone seeing None and thinking that they were setting their system to not have a preference, so making our actual "unset" value more explicit might make it more obvious what does what. While what we have now is consistent with --set "", I don't think we're advertising using set to remove a service level now that we have --unset. Do you feel like we're ok as is? (In reply to comment #4) > Do you feel like we're ok as is? I agree with mreid that a more explicit ["Not Set"|"No Preference"] string at the top of the drop-down list in the gui for service level setting is less ambiguous than a blank string. Same for release setting. I do feel that the current cli behavior is good as-is. in rhel-6.4
commit a2a1a2bd7d0ef32ef544824ecc11ba71ff96ae33
Author: Alex Wood <awood>
Date: Wed Nov 28 10:16:27 2012 -0500
839772: Display "Not Set" instead of "" in SLA and release preferences.
in master
commit 2bc346e3d6e447737c138a9b9ca8b0ad62f30f44
Author: Alex Wood <awood>
Date: Wed Nov 28 10:16:27 2012 -0500
839772: Display "Not Set" instead of "" in SLA and release preferences.
Created attachment 660616 [details]
Not Set String in release and service-level preferences
Verified!!
[root@rhel-64-server entitlement]# subscription-manager version
server type: Red Hat Subscription Management
subscription management server: 0.7.21-1
subscription-manager: 1.1.11-1.el6
python-rhsm: 1.1.6-1.el6
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. http://rhn.redhat.com/errata/RHBA-2013-0350.html |