-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Changes from 6 commits
816d442
0ae6ed0
8c91d8e
217a9ad
53cda84
91beb2f
6a2dcd2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -57,6 +57,33 @@ function migrateIndexPattern(doc) { | |
doc.attributes.kibanaSavedObjectMeta.searchSourceJSON = JSON.stringify(searchSource); | ||
} | ||
|
||
function removeDateHistogramTimeZones(doc) { | ||
const visStateJSON = get(doc, 'attributes.visState'); | ||
if (visStateJSON) { | ||
let visState; | ||
try { | ||
visState = JSON.parse(visStateJSON); | ||
} catch (e) { | ||
// Let it go, the data is invalid and we'll leave it as is | ||
} | ||
if (visState && visState.aggs) { | ||
visState.aggs.forEach(agg => { | ||
// We're checking always for the existance of agg.params here. This should always exist, but better | ||
// be safe then sorry during migrations. | ||
if (agg.type === 'date_histogram' && agg.params) { | ||
delete agg.params.time_zone; | ||
} | ||
|
||
if (get(agg, 'params.customBucket.type', null) === 'date_histogram' && agg.params.customBucket.params) { | ||
delete agg.params.customBucket.params.time_zone; | ||
} | ||
}); | ||
doc.attributes.visState = JSON.stringify(visState); | ||
} | ||
} | ||
return doc; | ||
} | ||
|
||
export const migrations = { | ||
'index-pattern': { | ||
'6.5.0': (doc) => { | ||
|
@@ -66,6 +93,17 @@ export const migrations = { | |
} | ||
}, | ||
visualization: { | ||
/** | ||
* We need to have this mirgation twice, once with a version prior to 7.0.0 once with a version | ||
timroes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
* after it. The reason for that is, that this migration has been introduced once 7.0.0 was already | ||
* released. Thus a user who already had 7.0.0 installed already got the 7.0.0 migrations below running, | ||
* so we need a version higher than that. But this fix was backported to the 6.7 release, meaning if we | ||
* would only have the 7.0.1 migration in here a user on the 6.7 release will migrate their saved objects | ||
* to the 7.0.1 state, and thus when updating their Kibana to 7.0, will never run the 7.0.0 migrations introduced | ||
* in that version. So we apply this twice, once with 6.7.2 and once with 7.0.1 while the backport to 6.7 | ||
* only contained the 6.7.2 migration and not the 7.0.1 migration. | ||
*/ | ||
'6.7.2': removeDateHistogramTimeZones, | ||
'7.0.0': (doc) => { | ||
// Set new "references" attribute | ||
doc.references = doc.references || []; | ||
|
@@ -146,6 +184,7 @@ export const migrations = { | |
throw new Error(`Failure attempting to migrate saved object '${doc.attributes.title}' - ${e}`); | ||
} | ||
}, | ||
'7.0.1': removeDateHistogramTimeZones, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
||
'7.1.0': doc => { | ||
// [TSVB] Migrate percentile-rank aggregation (value -> values) | ||
const migratePercentileRankAggregation = doc => { | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -160,6 +160,13 @@ export const dateHistogramBucketAgg = new BucketAggType({ | |
const isDefaultTimezone = config.isDefault('dateFormat:tz'); | ||
return isDefaultTimezone ? detectedTimezone || tzOffset : config.get('dateFormat:tz'); | ||
}, | ||
serialize() { | ||
// We don't want to store the `time_zone` parameter ever in the saved object for the visualization. | ||
// 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; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
||
}, | ||
}, | ||
{ | ||
name: 'drop_partials', | ||
|
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.
nit: lodash
omit
could save you from some conditionals here, e.g.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.
Would you prefer that? I find it actually harder to read, then the more explicit version :-)
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.
I think either is fine. Go with what you think is most obvious.
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.
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.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.
(And FWIW I had no issues groking the code as it is currently written)