Alerts feature breakdown Aug '19

@arikfr worked on your feedback:

View Mode

  1. Meta data moved to bottom right, but kept Last Triggered close to trigger state.
  2. “Edit” and “More” buttons in top right (like the Dashboard and Query pages convention).
  3. HelpTrigger removed.

Edit mode

  1. Removed “Save” Button.
  2. “Edit” button turns into “Done Editing” (like in Dashboard page).
  3. HelpTrigger appears.

Disable/Enable

  1. Renamed to “Mute Notifications”.

    48

  2. Clear indication when muted.

    44

When an alert page is kept open, it makes sense to expect that it auto updates.
We can do it the way Cypress Dashboard does:

  1. Auto checks every ~10 seconds.
  2. Allows to trigger manually on click.

32

Knowing that we’re planning to trigger Alert evaluation on edit, it makes even more sense to make this possible.

Wdyt?

1 Like

Why not Save? I know that’s what we did on dashboards, but there we auto save.

:+1: maybe only an icon is enough?

Mute Notifications implies that we keep checking alert status but don’t send notifications. It’s not the same as Disable.

I think this is out of scope at the moment.

@arikfr I’ve updated the preview instance.
Test out the flow - create a new alert, edit, save, add destinations, view with no edit permissions, etc.
If UX issues, write here. If dev issues, write in PR.

(Not implemented yet: Formatting guide docs)

Added a nice little feature of evaluating alert on the fly.

com-video-to-gif

1 Like

Edit View:

  • Do we need a cancel button?

View View:

  • Align top section (status) to the left?
  • Query link - add the arrow with cube thing? (like you have next to destinations)

Btw, did you test how this all looks like when someone doesn’t have permissions to edit the query opens the pages?

This is risky, because we can’t guarantee it works 100% the same as the backend. While those seems like super simple comparisons, here’s something I noticed already when testing: date/time column got converted to its Unix timestamp value and got compared as a number. This won’t happen on the backend…

Followed your rules, but not sure about this fragmentation :thinking:

New Alert:

The first screen (where you pick a query) is very different from the next one, while in current version when you pick a query the screen updates in a more “natural” way. It will be great to preserve this.

Do we need a cancel button?

Will do, as long as you’re ok it’ll basically just navigating to the view page.

Align top section (status) to the left?

No. Would look bad imo.

Query link - add the arrow with cube thing?

Basically unnecessary since there’s an underline + hover tooltip but I can add it.

Btw, did you test how this all looks like when someone doesn’t have permissions to edit the query opens the pages?

Yes indeed.

  1. alert/id/edit for the unauthorized serves the view page.
  2. Alert destinations are removable only if current user created them (unless admin).

This is risky, because we can’t guarantee it works 100% the same as the backend.

Fair enough. I’ll revert and push for evaluate-on-save.

It should show all of them.

It should show all of them.

It does - only talking about the remove icon.

The first screen (where you pick a query) is very different from the next one, while in current version when you pick a query the screen updates in a more “natural” way. It will be great to preserve this.

Done :+1:

Check recent changes in Preview Instance

The features in this topic have been implemented in PR 4153 and will be available in Redash version 9.

1 Like