Description of problem: When using the gui to subscribe to a pool that is "multi-entitlement" enabled, the contract selection dialog allows me to increase the quantity higher than 1. Problem 1: Currently, using the spinner to increase the quantity to a valid value, like 2, the subscribe seems to only consume 1 subscription. (I'm not sure what happened. this appeared to be working in the sprint demo last week). This appears to be a gui problem only. The cli allows me to subscribe to the same pool with --quantity=2 and it consumes two subscriptions. Problem 2: If the contract is for up to 13 subscriptions, the spinner button should be topped off at 13. Version-Release number of selected component (if applicable): [root@jsefler-onprem-62server ~]# rpm -qa | grep subscription-manager subscription-manager-firstboot-0.96.4-1.git.40.158de0a.el6.x86_64 subscription-manager-0.96.4-1.git.40.158de0a.el6.x86_64 subscription-manager-gnome-0.96.4-1.git.40.158de0a.el6.x86_64 Additional info: If testing with the TESTDATA imported into candlepin, then the "Awesome OS Server Basic (multi-entitlement)" pool can be used for this test.
[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