I suggest you ...

Alert history is not updated correctly from within widgets

The alert history is not updated when the resolution state of an alert is modified from within an alert widget.
In our case we have a dashboard with two alert views. Our ops guys use the context menu to set specific resolution states on the various alerts. That kind of action is not recorded in the history information of the alerts. However, it gets recorded when doing the exactly same steps from the default alerts view. Or by opening the alert and changing the status in there directly.

We had opened a premier ticket and were told that this is by design. To me it is a bug as it completely unexpected behaviour and creates inconsistent data in the database.

Still, we would like to see this changed

37 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Thorsten S shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
  • Eddy commented  ·   ·  Flag as inappropriate

    I agree this is bad design. The main reason the UserVoice is because CDCRs aren't taken for 2016 unless it is a blocking issue (no workaround) which this is not.

    the workarounds are simple
    a. don’t use right click, double click the alert and make the change from the open alert drop down menu
    b. use an active alert view for the same functionality

    CDCR would be filed for 1801, but PG won't be taken any until CB2 at the earliest. The issue stands a better chance of being fixed in upcoming version of the product, given the same reason you pointed out in your email. Having this filed on UserVoice so other users can upvote it increases the likelihood of it being taken by the PG.

  • Tyson commented  ·   ·  Flag as inappropriate

    It's sad that we should have to vote on this to get it fixed.
    Correction: .. to TRY to get enough attention to get this fixed.

Feedback and Knowledge Base