[Lens] Make Lens intervals default value adapt to histogram:maxBars Advanced Setting changes

[dej611]

Summary

Fixes #83420

This PR uses the UISettings histogram:maxBars value only as fallback in case the user hasn't changed the range input yet.
This makes the "default value" for the Interval UI dynamically change if a user changes the histogram:maxBars value in the Kibana Advanced Settings.

To test the feature

• Create a chart using the Interval operation
  • Drop a numeric field in the Horizontal axis area (preferably drop something with bigger ranges like price or bytes)
  • Open and close the Interval panel (do not change the range value).
  • Drop the Records field in the Vertical axis area
• Write down or take a screenshot of the chart to remember the interval size
• Save the chart as myIntervalChart1
• Create a secondary chart, this time like the previous, but do not open the Horizontal axis dimension panel.
• Write down or take a screenshot of the chart to remember the interval size also for this one
• Save it as myIntervalChart2
• Go to Stack Management > Advanced Settings
• Search for maxBars and change the value from 100 to 50
• Open the myIntervalChart1 and check that the interval has now changed (compare with the note/screenshot from before)
• Open the myIntervalChart2 and check that the interval has now changed (compare with the note/screenshot from before). It should be the same size as myIntervalChart1 one.

Tests have been re-adapted to follow the new behaviour.

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[dej611]

@elasticmachine merge upstream

[flash1293]

I tested this and it's not the same - if no value is set, the maximum number of buckets is chosen:

kibana/src/plugins/data/common/search/aggs/buckets/lib/histogram_calculate_interval.ts

Line 136 in 170a295

Math.min(maxBucketsUiSettings, maxBucketsUserInput || maxBucketsUiSettings),

The old logic (just if the panel is open), picked the middle between min and max number of buckets as default.

We either have to make maximum granularity the default in all cases (which means the slider is set to 100% at the beginning) or find a way to set it to "half of max precision" initially to make the behavior consistent.

These screenshots show the problem. I dragged bytes to the x axis, then moved the slider one tick and back:

[wylieconlon]

I tested this PR and agree with @flash1293 that we should restore the previous behavior of choosing 50% of max by default. I remember talking about using 100% of max, but we agreed at the time that it was a confusing UX- it's easier to understand at 50% because you can see there is room to make it denser.

[wylieconlon]

It looks like the problem is that we are now storing auto as the column param for maxBars instead of a specific number. So this triggers the fallback logic:

      // fallback to 0 in case of empty string
      maxBars: params.maxBars === AUTO_BARS ? undefined : params.maxBars,

which sets the max bars to 100%, instead of 50% like what the UI shows. So we probably need to change this fallback.

[flash1293]

I agree with Wylie, the issue why we can't easily do this in Lens is that we don't have access to ui settings in the toEsAggs function of the operation. I see two approaches:

• Pass uisettings into toEsAggs from the global toExpression function of the datasource
• Move the fallback to the histogram aggconfig

It probably makes sense to keep this in Lens for now.

[flash1293]

Looks like some places still have to be adjusted for the new call signature

[flash1293]

@elasticmachine merge upstream

[flash1293]

Tested and works as expected - as long as the user doesn't change something, auto is saved as interval. Doesn't fail even if the saved interval is out of the max bounds after changing it in advanced settings

[dej611]

Doesn't fail even if the saved interval is out of the max bounds after changing it in advanced settings

Is this an issue? It's kind of borderline, but I'd say to respect user's will in this case.

[flash1293]

No, I think it's fine. Just wanted to document I tested this case :)

[wylieconlon]

Changes LGTM!

[dej611]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: faf859f

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
lens	859.3KB	859.3KB	+49.0B

History

• 💚 Build #102090 succeeded 994d8d7
• 💔 Build #102068 failed daf688d
• 💔 Build #101837 failed b2f9fe0
• 💚 Build #101376 succeeded 1d86709
• 💚 Build #101121 succeeded c4f031e

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream