Description of problem: If a user comes to the All Available Subscriptions tab with the intent of subscribing to software they don't have installed yet, and their other subscriptions are taken care of, once they update their subscriptions, they still won't see anything in the table. They would have to look in the filters section and unselect options before anything showed up. I think we're being too aggressive with our pre-selected filters. It makes sense to me to filter on their hardware (Match my system), as those subscriptions wouldn't be useful to them, but I think we want to present more subscriptions to them, as we saw most users in the focus group stumble with the default filter settings (Match my installed products). I'm ok with "have no overlap" staying enabled by default, but if someone feels differently, I could be convinced. If we could have some sort of empty table text that lets the user know they have to press update, or that all of the results are filtered out, we might not need to alter the filter defaults. But since we have cases where the user can have subscription info pulled down, and still see nothing displayed in the table, I think we should look into altering the defaults so this can't happen. Version-Release number of selected component (if applicable): subscription-manager-1.0.1-1.git.8.701b271 Actual results: User updates subscription info, dialog pops up, system looks like its doing things, nothing shows in table, did anything even happen? Expected results: User updates subscription info, dialog pops up, system looks like its doing things, table is now populated with data. They can filter things down if they want. More natural to filter things out than filter things back in.
Fixed in subscription-manager.git: 712414c81154b516a3051b425002e99d071f68d2 Will appear in: subscription-manager-1.0.2-1 The matches installed products will now be unchecked by default, resulting in more options visible by default.
> > If we could have some sort of empty table text that lets the user know they > have to press update, or that all of the results are filtered out, we might > not need to alter the filter defaults. But since we have cases where the > user can have subscription info pulled down, and still see nothing displayed > in the table, I think we should look into altering the defaults so this > can't happen. > I've seen several first time users not know they had to click the update button to see any subscriptions. Perhaps we could have two messages, one that shows upon start-up that says something like "Press Update in order to retrieve subscription list." and then another message saying "No subscription matches selected filters." Setting this back to NEW for discussion on this.
So all solutions involving playing with that list of subscriptions to show other text did not feel right to me, we'd have to always be on the lookout for disabling all the related buttons and subscription details when the list didn't contain real subscriptions, not to mention getting a bunch of those columns to go empty. Instead I've added a label to display the messages we want, it is there initially telling you to hit Update to search for subscriptions. As soon as we have subs to display the label disappears and the list + details appear. If you adjust filters or re-search and there's nothing to show, we re-hide the list + details, and show a message indicating there are no subs matching current filters.
Fixed in: b7ed83c547b7508358d244f138402cdd3fffa132
Available in subscription-manager-1.0.7-1 and later.
Created attachment 597344 [details] "All available subscription" tab "update message" Version: # rpm -qa | egrep "subscription-manager|python-rhsm" subscription-manager-gui-1.0.8-1.git.14.dfc8438.el5 python-rhsm-1.0.3-1.git.0.583d26c.el5 subscription-manager-firstboot-1.0.8-1.git.14.dfc8438.el5 subscription-manager-1.0.8-1.git.14.dfc8438.el5 subscription-manager-migration-data-1.11.2.2-1.git.0.2eea155.el5 subscription-manager-migration-1.0.8-1.git.14.dfc8438.el5 Image in the background is prior to clicking on upddate Image in the foreground is when update is clicked and no appropriate entitlements are available. Moving bug to VERIFIED
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-0033.html