Bug 1003211 - RFE: Enhance recent alerts view with status and type filters
RFE: Enhance recent alerts view with status and type filters
Status: ON_QA
Product: RHQ Project
Classification: Other
Component: Core UI, Alerts (Show other bugs)
4.9
Unspecified Unspecified
medium Severity medium (vote)
: ---
: RHQ 4.13
Assigned To: Michael Burman
Mike Foley
:
: 1030667 (view as bug list)
Depends On: 1080171
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-31 17:08 EDT by Michael Burman
Modified: 2014-11-04 05:12 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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)
Adds filters and recovered status to RecentAlertsView and REST-interface. (34.06 KB, patch)
2013-10-23 17:39 EDT, Michael Burman
no flags Details | Diff

  None (edit)
Description Michael Burman 2013-08-31 17:08:13 EDT
Description of problem: Allow filtering of recent alerts with the following choices:

 - Acknowledged alerts
 - Recovery alerts
 - Alerts that have recovered

Also show new column "Recovered" which indicates if the alerts has recovered or not. The last one requires a change to domain model also, and to alert firing.
Comment 1 Michael Burman 2013-10-23 17:39:41 EDT
Created attachment 815572 [details]
Adds filters and recovered status to RecentAlertsView and REST-interface.

The following patch should work with the exception of Reports/RecentAlerts (the filters are available there, but for some reason they don't work).

What I'd need is input on did I approach this issue correctly and if the UI changes should be modified?
Comment 2 Elias Ross 2013-11-14 20:07:57 EST
+    @NamedQuery(name = Alert.QUERY_MARK_RECOVERED_BY_DEFINITION_ID, query = "" //
+        + "UPDATE Alert AS alert " //
+        + "   SET alert.recoveryTime = :recoveryTime " //
+        + "WHERE alert.id IN ( SELECT innerA.id " //
+        + "                      FROM AlertDefinition AS ad " //
+        + "                      JOIN ad.alerts AS innerA " //
+        + "                    WHERE ad.id = :alertDefinitionId )"
+        + "  AND alert.ctime < :recoveryTime " //
+        + "  AND alert.willRecover = true " //
+        + "  AND alert.recoveryTime < 0" // don't process again

The way I ack'ed in Bug 1030667 was to do:

            AlertDefinition rdef = getRecovered(def);

                log.debug("find existing alerts for " + rdef);
                for (Alert old : rdef.getAlerts()) {
                    ack(old);
                }

    private void ack(Alert alert) {
        if (alert.getAcknowledgingSubject() == null) {
            alert.setAcknowledgeTime(System.currentTimeMillis());
            String name = getSubject();
            alert.setAcknowledgingSubject(name);
            log.debug("ack " + alert);
        }
    }


Basically I just use Hibernate to find all the alerts for the definition, iterate, and if the ack subject is null, then update. This seems simpler than using an update query, though maybe not quite as scalable. (In practice, I don't think you'll have thousands of alerts for one definition, I hope.)

I don't see why you do recoveryTime < 0 when you could do 'recoveryTime is null', since it's not obvious that 'null < 0' .
Comment 3 Michael Burman 2013-11-15 04:41:41 EST
The recoverytime is actually a bigint/long in the database, like the ack_time (which structure I copied), so it's never null.
Comment 4 Jay Shaughnessy 2014-01-13 10:54:21 EST
Assigning this to myself for potential inclusion... No target yet.
Comment 5 Michael Burman 2014-11-04 05:11:00 EST
On master:

commit 65994bb1ae5d6475ceea937206f75a3a39143a66
Author: burmanm <miburman@redhat.com>
Date:   Mon Jul 14 14:58:42 2014 +0300

    [BZ 1003211] Adds automatic recovery information to the alerts if there's a recovery alert fired.
    
    [BZ 1003211] Add hovering support, and also add naming filter to the reports & REST interface
Comment 6 Michael Burman 2014-11-04 05:12:08 EST
*** Bug 1030667 has been marked as a duplicate of this bug. ***

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