This is a request on behalf of Mark Addy, who supplied an initial patch in Bug 846451. See there for more details but in brief: "From the main dashboard, or any view not associated to a group or resource the only users capable of acknowledging or deleting alerts are those with global permissions. The effect is that users with specific role permissions to manage alerts against a resource group must drill into the heirarchy before they can ack or delete those alerts."
master commit 88d0b566188d558842943f3ce7bd49a749054df9 Author: Jay Shaughnessy <jshaughn> Date: Fri Apr 5 16:43:20 2013 -0400 Based on contribution from mark Addy (thanks!) Change the "Delete" and "Acknowledge" alert buttons in the AlertHistoryView to use "ResourceAuthorizedTableAction" rather than "AbstractTableAction". This generates additional calls to the backend to check permissions on row selections (for non-admins). But, it should likely not be noticeable. I made one small optimization in ResourceAuthorizedTableAction. If constructed with a requiredPermission=null it will ignore the authz check. Using that we can make it perform like a standard table action. So, if in fact the user is an admin or otherwise has write access then it should act as before. I took away the isEnabled() overrides in the original patch in favor of this approach. The overrides had a small issue because they did not consider "enablement". Meaning the buttons would be active (for admins) even if nothing was selected.
verified. build: 2eef3b4 alert definitions can be deleted/acknowledged from both dashboard and group for admin user having only alert read/write and resource read permissions. please get screenshots attached.
Created attachment 754816 [details] alert_in_dashb
Created attachment 754817 [details] alert_in_inv
Created attachment 754818 [details] test_user_perm
Bulk close of old bugs in VERIFIED state.