Skip to content
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

[Visualize] Using format option in JSON input is not reflecting in the data #59703

Closed
tsullivan opened this issue Mar 9, 2020 · 2 comments
Closed
Labels
Feature:Vis Editor Visualization editor issues Team:Visualizations Visualization editors, elastic-charts and infrastructure

Comments

@tsullivan
Copy link
Member

tsullivan commented Mar 9, 2020

Kibana version: 7.6.1

Describe the bug:
The visualization builder features a JSON input text area where the user can add additional fields to the options of the aggregation.

One option available from Elasticsearch is format. The option shows up in the documentation for all of the aggregation types, but the permitted values about it are currently not well documented. (here is the docs issue: elastic/elasticsearch#53304)

Using format in the JSON input does cause the right thing to be sent to Elasticsearch, and returned from Elasticsearch. However, when it is used, Kibana displays the raw data instead of the formatted version, which is returned as value_as_string from Elasticsearc.h

Steps to reproduce:

  1. Create a data table visualization and add a single metric which is an overall average of count
    • Metric Agg: Average Bucket
    • Bucket Aggregation: Date Histogram
    • In the final JSON input textarea: { "format": "#" }
  2. Elasticsearch sends the request with the format field properly
{
  "aggs": {
    "3": {
      "avg_bucket": {
        "buckets_path": "3-bucket>_count",
        "format": "#"
      }
    },
    "3-bucket": {
      "date_histogram": {
        "field": "@date",
        "calendar_interval": "1w",
        "time_zone": "America/Phoenix",
        "min_doc_count": 1
      }
    }
  },
  1. Elasticsearch responds with the aggregated values formatted in value_as_string
  "aggregations": {
    "3": {
      "value": 66.66666666666667,
      "value_as_string": "67"
    },
  1. However, Kibana displays the non-integer version in the table:
    image

Expected behavior:
When Kibana is showing a value that's a result of a metric aggregation, it should defer to the value_as_string from the response data.

Or, there may be a better way to provide aggregation metric formatting to the user without requiring typing the options into JSON input.

Screenshots (if relevant):

Errors in browser console (if relevant):

Provide logs and/or server output (if relevant):

Any additional context:

@tsullivan tsullivan added Feature:Vis Editor Visualization editor issues Team:Visualizations Visualization editors, elastic-charts and infrastructure labels Mar 9, 2020
@elasticmachine
Copy link
Contributor

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

@timroes
Copy link
Contributor

timroes commented Mar 17, 2020

This is working as intended. We're having the advanced JSON input only for cases were the user might tweak the JSON, but we're not treating any of those parameters special. Meaning if it changes the response we won't take this into account. As long as we want to take it into account the parameter should get it's own setting in the UI and not be handled via the advanced JSON.

We're also not planning on changing that behavior in the future.

As far as I see from your screenshots, you're trying to use this parameter because field formatters to format the number wouldn't work for your config, because you're not formatting a field. I would refer to the issue of pulling field formatters closer to visualizations for this use-case: #16821

@timroes timroes closed this as completed Mar 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Vis Editor Visualization editor issues Team:Visualizations Visualization editors, elastic-charts and infrastructure
Projects
None yet
Development

No branches or pull requests

3 participants