Bug 949082

Summary: RFE: Allow alert ack/delete from recent alerts portlet and reporting view
Product: [Other] RHQ Project Reporter: Jay Shaughnessy <jshaughn>
Component: Core UIAssignee: Jay Shaughnessy <jshaughn>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: medium Docs Contact:
Priority: high    
Version: 4.6CC: ahovsepy, hrupp
Target Milestone: ---   
Target Release: RHQ 4.7   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-31 10:09:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
alert_in_dashb
none
alert_in_inv
none
test_user_perm none

Description Jay Shaughnessy 2013-04-05 20:18:12 UTC 
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."
Comment 1 Jay Shaughnessy 2013-04-06 00:27:32 UTC 
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.
Comment 2 Armine Hovsepyan 2013-05-30 12:28:42 UTC 
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.
Comment 3 Armine Hovsepyan 2013-05-30 12:29:17 UTC 
Created attachment 754816 [details]
alert_in_dashb
Comment 4 Armine Hovsepyan 2013-05-30 12:30:22 UTC 
Created attachment 754817 [details]
alert_in_inv
Comment 5 Armine Hovsepyan 2013-05-30 12:30:37 UTC 
Created attachment 754818 [details]
test_user_perm
Comment 6 Heiko W. Rupp 2013-08-31 10:09:45 UTC 
Bulk close of old bugs in VERIFIED state.