[Lens] Other bucket defaults to false for top values greater than equal 1000

[stratoula]

Summary

Closes #162456

It switches off the other bucket switch if the user updates the terms to a number greater than equal 1000.

In the beginning I had made it simpler so the switch would change to false if size >= 1000 and to true if size < 1000. But I am not sure I like this experience so I decided to do something else:

• The other bucket defaults to true if size < 1000
• If the user changes to a value >=1000 then it changes to false (The user can always enable it)
• If the user changes this to a value < 1000 it doesn't change back to true. The user must change it manually.

Let me know if you agree that this experience makes more sense.

Checklist

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

[elasticmachine]

Pinging @elastic/kibana-visualizations (Team:Visualizations)

[dej611]

I would expect to be notified, as a user, if as side effect of my input "automagically" switches a setting somewhere.
Recently we've been using info toasts to notify users when:

• using specific operations when random sampling is enabled
• using decimals in percentile/percentile rank when the column is used as ranking in Top values

Given that the Show Others options is also hidden by default behind the Advanced "curtains" I would propose to consider also in this case either the toast route, or alternative routes to notify users.

[stratoula]

@dej611 honestly i wanted to add a toast and I forgot it. I will update tmr :)

[stratoula]

@gchaps @amyjtechwriter can I have some help on the toast notification? The current state is:

This notification appears when the user changes the terms size from a value below 1000 to a value above. When this happens we set the Group remaining values as "Other" switch (which is on the advanced accordion) to false.

[stratoula]

@elasticmachine merge upstream

[dej611]

Tested again and it works fine 👍

I have only a personal opinion about the behaviour when, within the same editing session, the user changes from 100 to 1000, then restores back to 100.
If the Group remaining values as "Others" was enabled at 100 initially, I would expect the same state to be restored at the end. If the setting was disabled I would expect instead it to remain so.
Not a blocker for this PR, but the current behaviour of not restoring the initial state itches me a bit. 😅

[stratoula]

Thanx Marco, I am waiting for Gail's text proposal so I am not going to merge it without it.

I appreciate your review. Personally I think that at this case it is weird to enable it if the user types again the same number they had. This is an edge case and even if it happens we have already informed them with a notification that this switch is off. If we did what you propose in my mind it would require another notification because I don't think that it is expected that the switch will turn on again. We don't enable it for other cases so it is more confusing to enable it for this particular case. This complicates things in the UI without any good reason imho. (We can always change it if any user complains or finds it confusing)

[stratoula]

With the new texts

[gchaps]

Text LGTM

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 531b4c4

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	1.4MB	1.4MB	+911.0B

History

• 💛 Build #164479 was flaky 463a30f
• 💔 Build #164404 failed 6ecf3be
• 💔 Build #164327 failed e722453
• 💔 Build #164301 failed c707813
• 💛 Build #163272 was flaky 6daf603
• 💔 Build #163257 failed c35bada

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