Bug 662068 - all actions/buttons for recent alerts portlet always disabled. Unable to Ack alerts
Summary: all actions/buttons for recent alerts portlet always disabled. Unable to Ack ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Core UI
Version: 4.0.0.B02
Hardware: Unspecified
OS: Unspecified
low
medium vote
Target Milestone: ---
: ---
Assignee: Jay Shaughnessy
QA Contact: Corey Welton
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-12-10 14:12 UTC by Simeon Pinder
Modified: 2011-05-24 01:09 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-24 01:09:44 UTC


Attachments (Terms of Use)

Description Simeon Pinder 2010-12-10 14:12:04 UTC
Description of problem:
All actions/buttons for recent alerts portlet always disabled. Unable to Ack alerts. This used to work in earlier builds/releases.

Version-Release number of selected component (if applicable):


How reproducible:
Every time.

Steps to Reproduce:
1. Login as rhqadmin and view recent alerts in portlet view.
  
Actual results:
Unable to delete, acknowledge alerts directly from the portlet.

Expected results:
Buttons enabled/disabled as expected.

Additional info:
Navigating to the full alerts view for the resource, the buttons are correctly enabled to delete/ack alerts.

Comment 1 Jay Shaughnessy 2011-01-10 22:17:15 UTC
This is not as simple as it seems because the portlet view is a "subsystem" view of alerts. meaning it displays alerts for viewable resources [potentially] across groups with different permissions. So, a user may not have Alert permission on all of the displayed alerts. So, to enable the buttons correctly, in a fine-grained way, you need to permission check against all of the selected alerts.

This is a general auth/button enablement issue with "subsystem views", when a user may have varying permissions on list entries.

Comment 2 Jay Shaughnessy 2011-01-11 21:42:19 UTC
After some discussion the decision is that the main purpose of
portlets is to provide a quick overview of inventory status and, if not fast or easy, may not support everything the detailed views may support.  In this case the buttons will be hidden for non-inventory manager users. Other users can navigate quickly from the portlet to the detailed views via links provided in the alerts listed in the portlet.

Comment 3 Jay Shaughnessy 2011-01-11 21:46:09 UTC
commit edcb7e6230d6bd47593d2e6183e27c9afb30f2db

    In short this is due to the fact that the recent alerts portlet is like
    the recent alerts report, they are both "subsystem" views. As such the
    single alert listing can include alerts for which the user may or may
    not have alert (write) perms.  Both the portlet and the report view
    simply disallowed the buttons to be safe.  There are only really three
    alternatives, disallow all buttons, allow the buttons only for inv managers,
    or code up granular button enablement that involves perm checking on
    the resources backing each alert.
    
    I took option 2 which at least allows inv managers the ability to process
    the alerts en masse from the portlet or the report.  Other users will need
    to navigate to the alert or resource from the links provided, and process
    alerts from there.
    
    This change makes available the user's global perms to any portlet, and
    also any AbstractSectionedLeftNavigationView (the latter for the reports
    view).

Comment 4 Mike Foley 2011-05-02 13:00:36 UTC
verified RHQ 4.0 release candidate #1.  the recent alerts portlet's buttons have been removed and shows quick overview.  makes sense.

Comment 5 Corey Welton 2011-05-24 01:09:44 UTC
Bookkeeping - closing bug - fixed in recent release.


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