Bug 949082 - RFE: Allow alert ack/delete from recent alerts portlet and reporting view
RFE: Allow alert ack/delete from recent alerts portlet and reporting view
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
4.6
All All
high Severity medium (vote)
: ---
: RHQ 4.7
Assigned To: Jay Shaughnessy
Mike Foley
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-05 16:18 EDT by Jay Shaughnessy
Modified: 2013-08-31 06:09 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-31 06:09:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
alert_in_dashb (205.52 KB, image/png)
2013-05-30 08:29 EDT, Armine Hovsepyan
no flags Details
alert_in_inv (144.43 KB, image/png)
2013-05-30 08:30 EDT, Armine Hovsepyan
no flags Details
test_user_perm (242.82 KB, image/png)
2013-05-30 08:30 EDT, Armine Hovsepyan
no flags Details

  None (edit)
Description Jay Shaughnessy 2013-04-05 16:18:12 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."
Comment 1 Jay Shaughnessy 2013-04-05 20:27:32 EDT
master commit 88d0b566188d558842943f3ce7bd49a749054df9
Author: Jay Shaughnessy <jshaughn@redhat.com>
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 08:28:42 EDT
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 08:29:17 EDT
Created attachment 754816 [details]
alert_in_dashb
Comment 4 Armine Hovsepyan 2013-05-30 08:30:22 EDT
Created attachment 754817 [details]
alert_in_inv
Comment 5 Armine Hovsepyan 2013-05-30 08:30:37 EDT
Created attachment 754818 [details]
test_user_perm
Comment 6 Heiko W. Rupp 2013-08-31 06:09:45 EDT
Bulk close of old bugs in VERIFIED state.

Note You need to log in before you can comment on or make changes to this bug.