Bug 705181 - group, portlet or report alert history view may not display data
Summary: group, portlet or report alert history view may not display data
Alias: None
Product: RHQ Project
Classification: Other
Component: Core UI
Version: 4.0.1
Hardware: All
OS: All
high vote
Target Milestone: ---
: ---
Assignee: Jay Shaughnessy
QA Contact: Mike Foley
Depends On:
Blocks: jon3
TreeView+ depends on / blocked
Reported: 2011-05-16 21:19 UTC by Jay Shaughnessy
Modified: 2013-09-02 07:20 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2013-09-02 07:20:15 UTC

Attachments (Terms of Use)

Description Jay Shaughnessy 2011-05-16 21:19:44 UTC
This problem may reveal itself with alert history not showing up without a refresh or possibly with ancestry hover generating an exception.

Comment 1 Jay Shaughnessy 2011-05-16 23:02:37 UTC
commit 058a82ad8f3f1c6d39ce6691428838c70c9dacb2

Test Notes:
make sure you have some alert history for various resources, at least one in a group.  

Try Global dash recent alerts
Try resource dash recent alerts
Try resource alert history tab
Try group dash recent alerts
Try group alert history tab

Try hover on ancestry fields quickly after rendering of the rows.
Make sure refresh is not required to see the initial list of rows.
make sure portlet config is honored.

Comment 2 Mike Foley 2011-06-13 20:10:48 UTC
i am actually seeing the original behavior.  i create an alert that fires very frequently (on the platform resource, if free memory > 0).  i observe that history does not display any alerts.  if i click 'refresh', then the fired alerts appear.  this would seem to be the original behavior.  will discuss with jshaughn.

Comment 3 Mike Foley 2011-06-13 20:13:07 UTC
jshaughn, can you clarify?

Comment 4 Mike Foley 2011-06-13 20:38:03 UTC
clarification: if you are sitting on alerts-->history ...you DO need to click refresh (as I observed and documented above).  this issue is specifically if you navigate to alerts-->history that you don't additionally need to click refresh.  this behavior i am seeing.  assigning back to on_qa to verify the various scenarios described in comment 1

Comment 5 Heiko W. Rupp 2013-09-02 07:20:15 UTC
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.

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