Description of problem: When the access policy editor widget on the system page resubmits an existing rule that was only just created, it has no id locally. As a result the server treats this as a rule being removed and then re-added in the same request, even though the rule was actually not changed at all. Version-Release number of selected component (if applicable): 0.17 How reproducible: easily Steps to Reproduce: 1. Go to the Access Policy tab of the system page 2. Add a group to the access policy (one which was not already in the policy) 3. Click the checkbox to grant "View" permission to the new group 4. Click Save Changes 5. Click the checkbox to grant "Edit system" permission to that group 5. Click Save Changes 6. Check system activity records Actual results: 2014-08-28 16:04:05 +10:00 Access Policy Rule Removed <grant view to Admin> 2014-08-28 16:04:05 +10:00 Access Policy Rule Added <grant view to Admin> 2014-08-28 16:04:05 +10:00 Access Policy Rule Added <grant edit_policy to Admin> 2014-08-28 16:04:03 +10:00 Access Policy Rule Added <grant view to Admin> (Note that this was two separate HTTP requests, 2 seconds apart.) Expected results: 2014-08-28 16:04:05 +10:00 Access Policy Rule Added <grant edit_policy to Admin> 2014-08-28 16:04:03 +10:00 Access Policy Rule Added <grant view to Admin> (Redundant addition+removal of rule granting view permission to Admin should not appear.) Additional info: Only happens when the rule does not have an id stored client-side, but does exist in the policy. This only happens when you have added a new rule, saved it, and not refreshed the page yet.
It turns out this is already fixed on develop, most likely due to this commit: https://git.beaker-project.org/cgit/beaker/commit/?id=39df8a82f5f93c637b342aee2ab028a730227e6a
Verify on https://beaker-devel.app.eng.bos.redhat.com/ Steps 1. Add a group to access policy 2. Add view promission, add Edit system details promission. 3. Go to Activity tab check results. Change status to Verified.
Beaker 19.0 has been released.