Use SavedObjectsClient for Courier Index Pattern#12719
Use SavedObjectsClient for Courier Index Pattern#12719tylersmalley merged 12 commits intoelastic:masterfrom
Conversation
eec2e06 to
8991e22
Compare
* Index pattern is created, by default, with a random ID by Elasticsearch * Updated all references requiring the pattern itself to use indexPattern.title * Advanced options toggle added to index pattern creation page to provide a specified ID * If an index pattern does not exist, the user is given a link to create a pattern with the referenced ID. Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
8991e22 to
3025f46
Compare
|
This PR is similar to #12407 |
thomasneirynck
left a comment
There was a problem hiding this comment.
Lgtm from my end.
I did notice the following UX difference:
When a user creates a new index pattern, and uses a matching-pattern that already exists, the user is no longer presented with a dialog that ask whether they want to override the pattern. The practical result it that it is possible now to create multiple index-pattern that have identical titles:
|
@tbragin - what are your thoughts on @thomasneirynck's comment? Technically users can add index patterns with the same pattern but I could see how this could lead to customer confusion. If they attempt to create a pattern with the same name, what are your thoughts on presenting them with a popup linking them to the index pattern to manage? In my opinion, the "force overwrite" is confusing. Is it merging the attributes with the existing pattern, or completely swapping the pattern out and removing any scripts, etc? |
|
@tylersmalley @thomasneirynck I agree, duplicate index patterns could be pretty confusing to a user. Is there any reason why a user would want duplicate index pattern names? It seems as if it'd be best to avoid this situation as much as possible. We handled duplicate dashboard names (slightly different use case) with a simple warning. If we agree that there is no need to have duplicate index pattern names, I think the proposed solution with a warning and link to the index pattern management page makes sense. Though we may want to get UX's input here. I do have one question. Do we consider it a regression to remove the ability to override an index pattern? |
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
kobelb
left a comment
There was a problem hiding this comment.
There appear to be a number of bugs associated with switching from the index id to the title. Is there any possibility of avoiding this switch while still using the SavedObjectsClient?
| if (!config.get('defaultIndex')) { | ||
| config.set('defaultIndex', id); | ||
| } | ||
| if (!config.get('defaultIndex')) { |
There was a problem hiding this comment.
We're no longer refreshing the kibana index, do you mind explaining why this changed?
There was a problem hiding this comment.
The saved objects API uses refresh: wait_for when modifying objects instead of calling the refresh API directly to ensure the consistency.
| attributes: { | ||
| title: 'testIndexPattern' | ||
| }, | ||
| _version: 2 |
There was a problem hiding this comment.
It doesn't impact the test, but _version is actually version.
There was a problem hiding this comment.
It's actually _version since it comes from SavedObject - we can revisit later if that's ok.
| // Load the kibana app dependencies. | ||
|
|
||
| describe('Validate index name directive', function () { | ||
| // Fox |
There was a problem hiding this comment.
Not sure what this comment means...
| super( | ||
| `Could not locate that ${type}${idMsg}`, | ||
| SavedObjectNotFound); | ||
| let message = `Could not locate that ${type}${idMsg}`; |
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
There was a problem hiding this comment.
@spalger, there is a bug in marked that when a URL contains an asterisk it won't render the URL.
That project is really in a bad place - in the future we might want to find something else: https://github.com/chjj/marked/issues
ff588bd to
36e24dc
Compare
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
36e24dc to
143921f
Compare
* Index pattern is created, by default, with a random ID by Elasticsearch * Updated all references requiring the pattern itself to use indexPattern.title * Advanced options toggle added to index pattern creation page to provide a specified ID * If an index pattern does not exist, the user is given a link to create a pattern with the referenced ID.
* Index pattern is created, by default, with a random ID by Elasticsearch * Updated all references requiring the pattern itself to use indexPattern.title * Advanced options toggle added to index pattern creation page to provide a specified ID * If an index pattern does not exist, the user is given a link to create a pattern with the referenced ID.
|
5.x/5.6: 3c64283 |
|
Thanks @sophiec20, looking into that now. |
|
@tylersmalley This has been resolved now for ML under https://github.com/elastic/x-pack-kibana/pull/1954 |
|
Thanks @jgowdyelastic, apologies for the breaking change. |
ui-select-match's expression was expecting an IndexPattern object, but the indexPatternList passed to ui-select-choices contained SavedObject instances due to the [SavedObjectsClient refactor][1]. This wasn't a problem most of the time because switching index patterns caused the entire directive to get destroyed and re-created. However, when the directive didn't get re-created (for example, when clicking the already selected pattern) it would result in a blank select box. Fixes elastic#13080 [1]: elastic#12719
ui-select-match's expression was expecting an IndexPattern object, but the indexPatternList passed to ui-select-choices contained SavedObject instances due to the [SavedObjectsClient refactor][1]. This wasn't a problem most of the time because switching index patterns caused the entire directive to get destroyed and re-created. However, when the directive didn't get re-created (for example, when clicking the already selected pattern) it would result in a blank select box. Fixes #13080 [1]: #12719
ui-select-match's expression was expecting an IndexPattern object, but the indexPatternList passed to ui-select-choices contained SavedObject instances due to the [SavedObjectsClient refactor][1]. This wasn't a problem most of the time because switching index patterns caused the entire directive to get destroyed and re-created. However, when the directive didn't get re-created (for example, when clicking the already selected pattern) it would result in a blank select box. Fixes #13080 [1]: #12719
ui-select-match's expression was expecting an IndexPattern object, but the indexPatternList passed to ui-select-choices contained SavedObject instances due to the [SavedObjectsClient refactor][1]. This wasn't a problem most of the time because switching index patterns caused the entire directive to get destroyed and re-created. However, when the directive didn't get re-created (for example, when clicking the already selected pattern) it would result in a blank select box. Fixes #13080 [1]: #12719
ui-select-match's expression was expecting an IndexPattern object, but the indexPatternList passed to ui-select-choices contained SavedObject instances due to the [SavedObjectsClient refactor][1]. This wasn't a problem most of the time because switching index patterns caused the entire directive to get destroyed and re-created. However, when the directive didn't get re-created (for example, when clicking the already selected pattern) it would result in a blank select box. Fixes #13080 [1]: #12719






Uh oh!
There was an error while loading. Please reload this page.