Description of problem: When editing a puppet class, submitting the changes goes back to the list of all classes. This looses the user's context. It would be nice to return to the class itself or the actual page the edit was coming from. Additional info: Fixed upstream in e60ae306f720828681c2a072714ec3f515cb6376.
Moved to ON_QA as part of puddle 4.5.
I think this fails QE. It is true that, when creating a new puppet class, going through the tabs, etc., hitting submit remains within the context of the class itself. However, when choosing a pre-existing class, editing/updating something and hitting submit, user is returned to class View Not sure if this is just wording on part of the bz itself which is confusing or we've not fully implemented, but returning to dev for now. Feel free to bounce back to QE with clarification. * apr-util-ldap-1.3.9-3.el6_0.1.x86_64 * candlepin-0.8.9-1.el6_4.noarch * candlepin-scl-1-5.el6_4.noarch * candlepin-scl-quartz-2.1.5-5.el6_4.noarch * candlepin-scl-rhino-1.7R3-1.el6_4.noarch * candlepin-scl-runtime-1-5.el6_4.noarch * candlepin-selinux-0.8.9-1.el6_4.noarch * candlepin-tomcat6-0.8.9-1.el6_4.noarch * elasticsearch-0.19.9-8.el6sat.noarch * foreman-1.1.10009-1.noarch * foreman-compute-1.1.10009-1.noarch * foreman-installer-puppet-concat-0-2.d776701.git.0.21ef926.el6sat.noarch * foreman-installer-puppet-dhcp-0-5.3a4a13c.el6sat.noarch * foreman-installer-puppet-dns-0-7.fcae203.el6sat.noarch * foreman-installer-puppet-foreman-0-6.568c5c4.el6sat.noarch * foreman-installer-puppet-foreman_proxy-0-8.bd1e35d.el6sat.noarch * foreman-installer-puppet-puppet-0-3.ab46748.el6sat.noarch * foreman-installer-puppet-tftp-0-5.ea6c5e5.el6sat.noarch * foreman-installer-puppet-xinetd-0-50a267b8.git.0.44aca6a.el6sat.noarch * foreman-libvirt-1.1.10009-1.noarch * foreman-postgresql-1.1.10009-1.noarch * foreman-proxy-1.1.10003-1.el6sat.noarch * foreman-proxy-installer-1.0.1-8.f5ae2cd.el6sat.noarch * katello-1.4.2-12.el6sat.noarch * katello-all-1.4.2-12.el6sat.noarch * katello-candlepin-cert-key-pair-1.0-1.noarch * katello-certs-tools-1.4.2-2.el6sat.noarch * katello-cli-1.4.2-7.el6sat.noarch * katello-cli-common-1.4.2-7.el6sat.noarch * katello-common-1.4.2-12.el6sat.noarch * katello-configure-1.4.3-15.el6sat.noarch * katello-configure-foreman-1.4.3-15.el6sat.noarch * katello-foreman-all-1.4.2-12.el6sat.noarch * katello-glue-candlepin-1.4.2-12.el6sat.noarch * katello-glue-elasticsearch-1.4.2-12.el6sat.noarch * katello-glue-pulp-1.4.2-12.el6sat.noarch * katello-qpid-broker-key-pair-1.0-1.noarch * katello-qpid-client-key-pair-1.0-1.noarch * katello-selinux-1.4.3-3.el6sat.noarch * openldap-2.4.23-31.el6.x86_64 * pulp-rpm-plugins-2.1.1-1.el6sat.noarch * pulp-selinux-2.1.1-1.el6sat.noarch * pulp-server-2.1.1-1.el6sat.noarch * python-ldap-2.3.10-1.el6.x86_64 * ruby193-rubygem-ldap_fluff-0.2.2-1.el6sat.noarch * ruby193-rubygem-net-ldap-0.3.1-2.el6sat.noarch * signo-0.0.16-1.el6sat.noarch * signo-katello-0.0.16-1.el6sat.noarch
It's the wording of the BZ I think, this is by design. I thought the same when I saw the initial PR, see the discussion including from David, the user who filed the original issue: https://github.com/theforeman/foreman/pull/633 The intention is that a user can search for a class on the puppet classes list page, clicks on the class, edits it, presses submit and then returns to the class list but in the same position they were before (with search terms and page number preserved). It isn't intended (yet) to work as an "apply" button and remain on the puppet class page itself.
Thanks for the explanation. QE Verified.
mass move to CLOSED:CURRENTRELEASE since MDP1 has been released.