Description of problem: Unclear choice of adding administration roles for the read-only users. We have read-only user and we can also choose another roles, what is unnecessary. The main problem is that, if we has the read only user and we give him the new (admin) roles, we will not able to remove them. We get message "At least one Organization Administrator with regular access must remain in Red Hat SatTeam QA organization.". Version-Release number of selected component (if applicable): Sat 5.7 (spacewalk-java-2.3.8-15.el6sat.noarch) How reproducible: 100% Steps to Reproduce: 1. create read-only user 2. give him the role "Organization Administrator" 3. kick out him from the role "Organization Administrator" Actual results: "At least one Organization Administrator with regular access must remain in Red Hat SatTeam QA organization." Expected results: We will able to remove him from role "Organization Administrator" or better solution, we will not able to give him the role "Organization Administrator" or roles. Additional info:
Taking ...
Several issues found and fixed ... spacewalk.git: eea27da642cae848544529a8bc0de31d5709c902 (behave differently when the user was a readonly one before the change) 66a47a20992e3bbe82ba7e678bf7d79f479a2859 (enhance rhnWebContactEnabled view) 73eaa8685e9364e054226f8625e649b50f683e13 (change readOnly hbm type to yes_no) ad4e589f39314cf847989e0663c9856c43e29067 (enhance Org.numOfOrgAdmins sql-query)
Verified on Satellite-5.7.0-RHEL6-re20141001.0 (spacewalk-java-2.3.8-28.el6sat, spacewalk-schema-2.3.2-7.el6sat).
With the release of Red Hat Satellite 5.7 on January 12th 2015 this bug is being moved to a Closed Current Release state. The Satellite 5.7 GA Errata: - https://rhn.redhat.com/errata/RHSA-2015-0033.html Satellite 5.7 Release Notes: - https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/5.7/html-single/Release_Notes/index.html Satellite Customer Portal Blog announcement for release: - https://access.redhat.com/blogs/1169563/posts/1315743 Cliff NOTE: This bug has not been re-verified (moved to RELEASE_PENDING) prior to release. We assume that the bug has indeed been fixed and not regressed since we initially verified it. Please re-open in the future if needed.