Bug 723248
| Summary: | subscription-manager-gui is ignoring the quanties>1 on a pool with multi-entitlement | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | John Sefler <jsefler> | ||||
| Component: | subscription-manager | Assignee: | Bryan Kearney <bkearney> | ||||
| Status: | CLOSED ERRATA | QA Contact: | John Sefler <jsefler> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 5.7 | CC: | jmolet, spandey, wpoteat | ||||
| Target Milestone: | beta | ||||||
| Target Release: | 5.8 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: |
No description necessary
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-02-21 06:41:32 UTC | Type: | --- | ||||
| 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: | 715031 | ||||||
| Attachments: |
|
||||||
|
Description
John Sefler
2011-07-19 14:17:17 UTC
[root@jsefler-onprem-62server ~]# rpm -q python-rhsm python-rhsm-0.96.7-1.git.3.f3ce5d1.el6.noarch Created attachment 513825 [details]
some observations to reproduce/avoid this bug
In the attached screenshot, the user has incremented the spinner and if he then clicks Subscribe, only 1 of the subscriptions will be consumed.
It appears that the new quantity value in the spinner is not actually committed yet. If the user re-clicks the row, then the new spinner value seems to get comitted for quantity and a click on Subscribe correct consumes the desired quantity.
I also realize that there was a recent usability design review (on 7/15/2011) regarding the workflow ro specify a quantity in the gui and this implementation is subject to change.
(In reply to comment #0) > > Problem 2: If the contract is for up to 13 subscriptions, the spinner button > should be topped off at 13. > The spinbutton should be limited here and do built in checking. Its max needs to be the difference of the quantity consumed and the quantity available. Its min needs to be 0 or 1 (not sure which would be better). Currently you can select negative numbers, or numbers too great. When this happens the contract selection dialog closes and you either have to discover your error by going to the "My subscriptions" tab or by the error pop up. In either case you have to search for the subscription and start the subscribe process over again. We could save the user a lot of time here. (In reply to comment #2) > In the attached screenshot, the user has incremented the spinner and if he then > clicks Subscribe, only 1 of the subscriptions will be consumed. > > It appears that the new quantity value in the spinner is not actually committed > yet. If the user re-clicks the row, then the new spinner value seems to get > comitted for quantity and a click on Subscribe correct consumes the desired > quantity. Problem #1 This is now fixed in the master branch at 75efb0acc19648bfdde1ca9987a91a1837f69b79 (In reply to comment #3) > (In reply to comment #0) > > > > Problem 2: If the contract is for up to 13 subscriptions, the spinner button > > should be topped off at 13. > > > > The spinbutton should be limited here and do built in checking. Its max needs > to be the difference of the quantity consumed and the quantity available. Its > min needs to be 0 or 1 (not sure which would be better). Currently you can > select negative numbers, or numbers too great. When this happens the contract > selection dialog closes and you either have to discover your error by going to > the "My subscriptions" tab or by the error pop up. In either case you have to > search for the subscription and start the subscribe process over again. We > could save the user a lot of time here. As of 32614970381e53f323503a82e35683f1031a11eb if the quantity is NOT greater than 0, an error box is presented and the contract selector/subscription assistant dialog stays open. NOTE: We still DO NOT enforce a maximum value, and the bug should remain open until we fix that problem. *** Bug 755861 has been marked as a duplicate of this bug. *** Testing against build: subscription-manager-gnome-0.98.7-1.git.2.a7a5a30.el5_7 I've tested this this in the following scenarios: - Subscription Assistant - All available Subscriptions - Contract Selections In each case I've verified that the max/min values are set correctly, and that the quantity can be changed with both text entry and the arrow buttons. When subscribed to, it actually subscribes the requested number of entitlements. Though the max values are set correctly for simple cases, you quickly run into edge cases. Will open a bug on this separately. As the max value has been pushed to the backlog in comment 8, I'm marking this VERIFIED as basic functionality works here.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
No description necessary
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-2012-0154.html |