Red Hat Bugzilla – Bug 949082
RFE: Allow alert ack/delete from recent alerts portlet and reporting view
Last modified: 2013-08-31 06:09:45 EDT
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 <firstname.lastname@example.org>
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.
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]
Created attachment 754817 [details]
Created attachment 754818 [details]
Bulk close of old bugs in VERIFIED state.