Red Hat Bugzilla – Bug 1225923
Content > Red Hat Subscriptions landing page/endpoint is not uniform
Last modified: 2016-07-27 04:52:18 EDT
Description of problem: Sometimes when user navigates to Content > Red Hat Subscriptions, they are taken to /subscriptions ... but other times when navigating, via the UI, to the same location, they are taken/redirected to /subscriptions/manifest/import Version-Release number of selected component (if applicable): Snap6 How reproducible: I have one reproducible case but I am not sure it is the best Steps to Reproduce: 1. Install satellite. Navigate to Content > Lifecycle Environments (or nearly anywhere else in the UI) and then to Content > Red Hat Subscriptions 2. Observe user is taken to /subscriptions/manifest/import endpoint 3. From within the Subscriptions page itself (and perhaps other pages?) nav to Content > Red Hat Subscriptions 4. Observe results. Actual results: Depending where you are or in certain circumstances (heuristic not completely known though as noted we have a repro case here), "Content > Red Hat Subscriptions" takes user to one of two different endpoints. Expected results: Content > Red Hat Subscriptions always take user to same page/endpoint. Additional info: Such behavior is confusing and will lead to support calls with people wondering what is going on. I am willing to remove blocker if: (a) the heuristic is fully determined and (b) found to be limited to navigating to "Content > Red Hat Subscriptions" from within the Manage/Import Manifests page itself, and (b) This is doc'd.
Created redmine issue http://projects.theforeman.org/issues/10721 from this bug
I personally don't think this meets the qualifications for high severity and for going into a point release.
Upstream bug assigned to ehelms@redhat.com
Moving to POST since upstream bug http://projects.theforeman.org/issues/10721 has been closed ------------- Eric Helms Applied in changeset commit:katello|2c38e0689ff3918cc052e86887a3aaecaf9ee275.
*** This bug is verified in upstream. This fix should eventually land in future downstream builds *** VERIFIED: # rpm -qa | grep foreman nec-em17.rhts.eng.bos.redhat.com-foreman-client-1.0-1.noarch foreman-1.11.0-0.develop.201510121538gitb6b977a.el7.noarch tfm-rubygem-hammer_cli_foreman_docker-0.0.3-4.el7.noarch nec-em17.rhts.eng.bos.redhat.com-foreman-proxy-client-1.0-1.noarch tfm-rubygem-hammer_cli_foreman-0.4.0-1.201510071112git33fd59b.el7.noarch foreman-debug-1.11.0-0.develop.201510121538gitb6b977a.el7.noarch foreman-release-1.11.0-0.develop.201510121538gitb6b977a.el7.noarch foreman-postgresql-1.11.0-0.develop.201510121538gitb6b977a.el7.noarch foreman-vmware-1.11.0-0.develop.201510121538gitb6b977a.el7.noarch tfm-rubygem-foreman_hooks-0.3.9-1.el7.noarch tfm-rubygem-foreman-tasks-0.7.6-1.fm1_10.el7.noarch tfm-rubygem-hammer_cli_foreman_tasks-0.0.8-1.el7.noarch tfm-rubygem-foreman_bootdisk-6.0.0-2.fm1_10.el7.noarch foreman-release-scl-1-1.el7.x86_64 foreman-libvirt-1.11.0-0.develop.201510121538gitb6b977a.el7.noarch foreman-selinux-1.11.0-0.develop.201510071426git6234447.el7.noarch foreman-ovirt-1.11.0-0.develop.201510121538gitb6b977a.el7.noarch tfm-rubygem-hammer_cli_foreman_bootdisk-0.1.3-3.el7.noarch tfm-rubygem-foreman_gutterball-0.0.1-3.el7.noarch nec-em17.rhts.eng.bos.redhat.com-foreman-proxy-1.0-2.noarch tfm-rubygem-foreman_discovery-4.1.0-1.fm1_10.el7.noarch tfm-rubygem-foreman_docker-1.4.1-2.fm1_10.el7.noarch foreman-proxy-1.11.0-0.develop.201510120849git5f36f2e.el7.noarch foreman-compute-1.11.0-0.develop.201510121538gitb6b977a.el7.noarch foreman-gce-1.11.0-0.develop.201510121538gitb6b977a.el7.noarch
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. https://access.redhat.com/errata/RHBA-2016:1500