New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Lens] Restore operation auto switch based on field type #127861
Conversation
Pinging @elastic/kibana-vis-editors @elastic/kibana-vis-editors-external (Team:VisEditors) |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noticed a problem, took care of that. Approving as it works fine otherwise
// in single field mode, allow the automatic switch of the function to | ||
// the most appropriate one | ||
if (fields.length === 1) { | ||
const newFieldOp = operationSupportMatrix.operationByField[sourcefield] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This shouldn't just check for the first op, but whether terms
is in the list or not. Right now switching to a number field while in "Top values" will switch to "Intervals" even though top values on a number field is a valid thing to do
💛 Build succeeded, but was flakyMetrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
Summary
Fixes #127258
This PR restores a previous Lens behaviour when having a single field in Top values which wasn't supported: before multi terms the panel would automatically switch to a supported operation.
While investigating this change I've noticed that the field_select logic was relying on the assumption
fieldName === displayName
, which was not true. So I've also fixed this bug (noticetimestampLabel
for thetimestamp
field):To test:
Checklist
Delete any items that are not applicable to this PR.
Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:
For maintainers