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

Don't save the current timezone in visualizations #34795

Merged
merged 7 commits into from
Apr 11, 2019

Conversation

timroes
Copy link
Contributor

@timroes timroes commented Apr 9, 2019

Summary

Fixes #34784

Since the introduction of rollups we technically had the possibility to specify a time_zone for a date_histogram in the AggConfig. This was needed so the rollup plugin can overwrite the timezone by the one from the rollup job. Unfortunately that means the time_zone was also serialized and saved in the saved object when saving the visualization, meaning every visualization you created since 6.5 with a date histogram in it basically stored the time zone of the user creating it for the date_histogram.

This means if a user in a different time zone or if you change your Kibana's time_zone, you'll still see that saved visualization in the time zone it was saved in. That's a very bad behavior since it basically breaks collaboration over multiple time zones and changing your Kibana's time zone.

This PR fixes that behavior by making sure the time_zone parameter won't be saved in the saved object anymore, but only lives transient "in memory".

It also migrates all saved visualizations to remove the stored time_zone from it, since there is no legit state where you want to store it with the visualization.

@LeeDr and/or @bhavyarm since this fix is going back to 6.7 and we're migrating all saved object I would appreciate if one of you could give this a QA test too, before merging.

Steps to reproduce

  1. Create any visualization with a date_histogram in it.
  2. Change your Kibana's timezone in the advanced settings and reload the page.
  3. Open the visualization again.
  4. Failure: It will still show the data in the old time_zone. You can also check the saved object. It will have a params.time_zone in the date_histogram in visState.aggs which shouldn't be there.

If possible also test migrating of old documents. If you save an visualization before that fix, it will have that params.time_zone in it (and render in that time zone no matter what you configured in Kibana). If you apply that fix, your saved object should be fixed and the time_zone should be removed from all date_histogram aggregations.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

For maintainers

@timroes timroes added bug Fixes for quality problems that affect the customer experience Feature:Aggregations Aggregation infrastructure (AggConfig, esaggs, ...) release_note:fix Team:Visualizations Visualization editors, elastic-charts and infrastructure v8.0.0 v7.2.0 v7.0.1 v6.7.2 labels Apr 9, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app

@@ -146,6 +175,7 @@ export const migrations = {
throw new Error(`Failure attempting to migrate saved object '${doc.attributes.title}' - ${e}`);
}
},
'7.0.1': removeDateHistogramTimeZones,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tylersmalley I already talked to Chris, but we wanted to clarify with you that our thoughts were correct:

In the backport to 6.7, I'll remove this 7.0.1 migration and just leave the 6.7 migration in. But since we already released 7.0, and potentially have now people on that version that should get the same fix, we need both 6.7.2 and 7.0.1 to do the migrations. Also just adding a 7.0.1 wouldn't be good, since if we backport this to 6.7 a user who runs the 7.0.1 migration on 6.7 would then, after upgrading to 7.0.1+, not get all the 7.0.0 migrations.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should only be one - one of these needs to be removed. It doesn't necessarily have to follow the versioning of Kibana. On startup, it will see if there are any newer versions for the visualization type, we will run those migrations to get up to that version.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there needs to be 2, because some clients will have run the 7.0.0 migrations already, but some will not have (those running 6.x). And we want to fix both people without forcing the 6.x people to upgrade to 7.x. Does that make sense, @tylersmalley

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We talked about that offline and it makes sense now to everyone. I updated the code to have a better explanation why we need it twice.

@elasticmachine
Copy link
Contributor

💔 Build Failed

@bhavyarm
Copy link
Contributor

bhavyarm commented Apr 9, 2019

@timroes I will test it tomorrow! Cheers.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Member

@lukeelmers lukeelmers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed code; still need to test. Overall LGTM, just a couple nits. Will try to get this tested tomorrow.

@@ -57,6 +57,34 @@ function migrateIndexPattern(doc) {
doc.attributes.kibanaSavedObjectMeta.searchSourceJSON = JSON.stringify(searchSource);
}

function removeDateHistogramTimeZones(doc) {
const newDoc = cloneDeep(doc);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Not a huge thing, but you don't necessarily need to clone every doc that comes in since you are only going to be updating attributes.visState on date histograms. You could return early if the doc is not identified as needing to be changed, and only clone / reassign the visState on docs that you know you need to touch.


if (get(agg, 'params.customBucket.type', null) === 'date_histogram' && agg.params.customBucket.params) {
delete agg.params.customBucket.params.time_zone;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: lodash omit could save you from some conditionals here, e.g.

if (agg.type === 'date_histogram' || get(agg, 'params.customBucket.type') === 'date_histogram') {
  agg.params = omit(agg.params, ['time_zone', 'customBucket.params.time_zone']);
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you prefer that? I find it actually harder to read, then the more explicit version :-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think either is fine. Go with what you think is most obvious.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I marked it as a nit for a reason 😉 Totally up to your preference here, I only suggested it because omit will automatically skip things that are undefined.

Copy link
Member

@lukeelmers lukeelmers Apr 10, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(And FWIW I had no issues groking the code as it is currently written)

// If we would store this changing the time zone in Kibana would not affect any already saved visualizations
// anymore, which is not the desired behavior. So always returning undefined here, makes sure we're never
// saving that parameter and just keep it "transient".
return undefined;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, glad you explained this to minimize "WTF moments" in the future.

@elasticmachine
Copy link
Contributor

💔 Build Failed

Copy link
Contributor

@chrisdavies chrisdavies left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Member

@lukeelmers lukeelmers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Finally got the chance to test this (Chrome OSX)... I created a new vis with a date_histogram agg, saved it, manually updated the migrationVersion to something older, restarted the Kibana server, and verified the migration ran and correctly removed the time_zone param.

src/legacy/core_plugins/kibana/migrations.js Outdated Show resolved Hide resolved
Co-Authored-By: timroes <mail@timroes.de>
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@bhavyarm
Copy link
Contributor

LGTM. Tested it on chrome OSX. No time_zone in date histogram in saved objects.

@timroes timroes merged commit aab98ae into elastic:master Apr 11, 2019
@timroes timroes deleted the fix-date-histogram-tz branch April 11, 2019 12:24
timroes added a commit to timroes/kibana that referenced this pull request Apr 11, 2019
* Don't save the current timezone in visualizations

* Add additional test

* Add test and switch migration number

* Don't clone object according to review feedback

* Better documentation

* Update src/legacy/core_plugins/kibana/migrations.js

Co-Authored-By: timroes <mail@timroes.de>
timroes added a commit to timroes/kibana that referenced this pull request Apr 11, 2019
* Don't save the current timezone in visualizations

* Add additional test

* Add test and switch migration number

* Don't clone object according to review feedback

* Better documentation

* Update src/legacy/core_plugins/kibana/migrations.js

Co-Authored-By: timroes <mail@timroes.de>
timroes added a commit to timroes/kibana that referenced this pull request Apr 11, 2019
* Don't save the current timezone in visualizations

* Add additional test

* Add test and switch migration number

* Don't clone object according to review feedback

* Better documentation

* Update src/legacy/core_plugins/kibana/migrations.js

Co-Authored-By: timroes <mail@timroes.de>
timroes added a commit that referenced this pull request Apr 11, 2019
* Don't save the current timezone in visualizations

* Add additional test

* Add test and switch migration number

* Don't clone object according to review feedback

* Better documentation

* Update src/legacy/core_plugins/kibana/migrations.js

Co-Authored-By: timroes <mail@timroes.de>
timroes added a commit that referenced this pull request Apr 12, 2019
)

* Don't save the current timezone in visualizations (#34795)

* Don't save the current timezone in visualizations

* Add additional test

* Add test and switch migration number

* Don't clone object according to review feedback

* Better documentation

* Update src/legacy/core_plugins/kibana/migrations.js

Co-Authored-By: timroes <mail@timroes.de>

* Fix migrationVersion in tests
timroes added a commit that referenced this pull request Apr 15, 2019
)

* Don't save the current timezone in visualizations (#34795)

* Don't save the current timezone in visualizations

* Add additional test

* Add test and switch migration number

* Don't clone object according to review feedback

* Better documentation

* Update src/legacy/core_plugins/kibana/migrations.js

Co-Authored-By: timroes <mail@timroes.de>

* Fix migrationVersion in integration tests

* Fix tests

* Fix migrationVersion in tests

* Fix more tests
chandlerprall pushed a commit to chandlerprall/kibana that referenced this pull request Apr 15, 2019
* Don't save the current timezone in visualizations

* Add additional test

* Add test and switch migration number

* Don't clone object according to review feedback

* Better documentation

* Update src/legacy/core_plugins/kibana/migrations.js

Co-Authored-By: timroes <mail@timroes.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience Feature:Aggregations Aggregation infrastructure (AggConfig, esaggs, ...) release_note:fix Team:Visualizations Visualization editors, elastic-charts and infrastructure v6.7.2 v7.0.1 v7.2.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Timezone change in Kibana not reflecting on existing visualization
6 participants