Feature: Flexible Y-Min and Y-Max settings.

[thoj]

Possible Issues: #979 #4156 #3935 #2759

Y-Min and Y-Max is now string.
New usage for both Y-Min and Y-Max (Where X is a real number):

  >X Y-Max/Y-Max is auto if data is above X else X
  <X Y-Max/Y-Min is auto if data is below X else X
  =X Y-Max/Y-Min is scaled to current value +/- X
  ~X Y-Max/Y-Min is caled to average value +/- X

Example: Y-Min: <100 Y-Max: >200
If all points are within 100 and 200: Y-Min is 100 and Y-Max is 200
If some points are above 200: Y-Min is 100 and Y-Max is auto
If some points are below 100: Y-Min is auto and Y-Max is 200
if some points are below 100 and above 200: Y-Min and Y-Max is auto

Unit tests for new settings added

More Examples:
In the following images you see temperature gauges that when using default auto-scaling is either noisy or show very little information because of a few values that are close to zero.

I can't set Y-Min and Y-Max because the temperatures will wander to much over a few days and would fall outside of Y-Min and Y-Max pretty quickly.

[lpalm]

This is great.

The "<X" and ">X" functions could potentially be applied directly to the Y-Min and Y-Max, respectively. This would allow for fine control over the min and max ranges separately. It could be useful when certain fixed Y values are important (e.g. 0 or some threshold), but still allowing points that cross those Y values to be displayed.

Example:
Having a Level 1 threshold of 600 ("minimum") degrees and a level 2 threshold of 800 ("maximum") that are always visible on the graph, but still allowing points <600 or >800 to be visible if they're present. Having a minimum span of 200 would almost always work, but would hide the thresholds if we zoomed into a range where all points are in the range 1000-1100, for example.

[torkelo]

This is interesting, might need some refactoring and unit tests, and worth exploring @lpalm idea of having option for Y-Min and Y-Max separately. Another idea is to use the Y-Min and Y-max options for this (to allow strings in this input field as well)

[lpalm]

Yeah, I figured we might as well allow strings in the Y-Min/Max fields to save space.

[thoj]

I'll se what I can do :) Thanks for your ideas :)

[thoj]

@lpalm @torkelo Did som refactoring and added unit tests. Now just using Y-Min and Y-Max.

@lpalm if you look at the first example image I think this is what you wanted?

p.s. This is the first time I've done unit tests in angular and it took me some time to gork, hope it's done right.

[lpalm]

Should we do:
/([<=>~]?)\W*(\d+(\.\d+)?)/
Or even (assuming we want to support >=, <=, which don't matter much for floating point, but may be more intuitive):
/(<|<=|>|>=|~|=)?\W*(\d+(\.\d+)?)/

Instead of:
/([<=>~]*)\W*(\d+(\.\d+)?)/

(Same for the Y-Max)

[thoj]

@lpalm I have a bit of a difficult time figuring out where <= and >= would be useful? Could you explain one case for me?

I agree that the regex could be a lot better. I think we need \W* because \W would enforce a white space.

[lpalm]

It wouldn't be useful. Rather, it may be nice to treat >= as > and <= as < instead of just not working. Don't feel strongly about it.

Apologies about the \W*, looks like github treated the asterisk as an indication to italicize my text! I've edited it to be in block quotes now.

[lpalm]

I'm not super familiar with the Grafana code base and style but LGTM! Thanks for putting this in, @thoj. And yes, that screenshot is exactly what I had in mind.

[torkelo]

sorry, this PR was refactored a bit in this PR (#6051) , I hit squash merge commit without thinking that this PR would not then be automatically detected as merged by github.

Anyway, the feature is in master now, thank you for making Grafana better ❤️ !

[torkelo]

closing this as this PR has drifted a bit too far from master.

Need to figure out a UI for the expressions so they are discoverable (and not secret things you need to know about)