Bug 1003211

Summary: RFE: Enhance recent alerts view with status and type filters
Product: [Other] RHQ Project Reporter: Michael Burman <yak>
Component: Core UI, AlertsAssignee: Nobody <nobody>
Status: ON_QA --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4.9CC: genman, hrupp, jshaughn
Target Milestone: ---   
Target Release: RHQ 4.13   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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: --- Target Upstream Version:
Bug Depends On: 1080171    
Bug Blocks:    
Attachments:
Description Flags
Adds filters and recovered status to RecentAlertsView and REST-interface. none

Description Michael Burman 2013-08-31 21:08:13 UTC 
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 21:39:41 UTC 
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-15 01:07:57 UTC 
+    @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 09:41:41 UTC 
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 15:54:21 UTC 
Assigning this to myself for potential inclusion... No target yet.
Comment 5 Michael Burman 2014-11-04 10:11:00 UTC 
On master:

commit 65994bb1ae5d6475ceea937206f75a3a39143a66
Author: burmanm <miburman>
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 10:12:08 UTC 
*** Bug 1030667 has been marked as a duplicate of this bug. ***