MySQL Bugs: #33826: Better event chain reporting

Bug #33826	Better event chain reporting
Submitted:	11 Jan 2008 20:32	Modified:	30 Jun 2009 14:09
Reporter:	Todd Farmer (OCA)	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Enterprise Monitor: Web	Severity:	S4 (Feature request)
Version:	1.2	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	jira_sync

Description:
The "[time] ago" values reported in the MEM UI are misleading, as it is calculated from the start time of the most recent event.  If the event also happened earlier and was not cleared, this value will show as the date/time next to this field.  So you can end up with values like:

Nov 19, 2007 3:48:05 AM (1 day, 11 hours ago)

in December.

How to repeat:
Create a condition that causes an event to be reported in MEM.
Don't clear the event.
Change the condition so that it no longer exists.
Re-create the same condition.
Note the date/time and NNN ago values do not reconcile.

Suggested fix:
The date/time the event first started, and the start time of the most current event incident, are two different reporting items and should be treated as such.

Better yet, expose the entire event chain through the UI.

The displayed time and hover for time ago are based on the same value, severe alarm time. They should match up now. It may have been that the time ago was using current alarm time when this bug was reported.

Note that 2.0 also displays the current alarm state as a column on the events page and dashboard. Pending work is to display this state in the popup and to display the history of alarm changes. I will open a separate bug for that.

removing "2.0" tag, since it wasn't included in 2.0.