[Discover] Support storing time with saved searches#138377
Conversation
| label={ | ||
| <FormattedMessage | ||
| id="discover.topNav.saveModal.storeTimeWithSearchFormRowLabel" | ||
| defaultMessage="Store time with search" |
There was a problem hiding this comment.
Hi @gchaps ! We are adding a new toggle to the Save Search modal on Discover page. Do you have suggestions for the copy?
There was a problem hiding this comment.
How about something like this
Store time with saved search
Update the time filter and refresh interval to the current selection when using this search.
|
@elasticmachine merge upstream |
|
Pinging @elastic/kibana-data-discovery (Team:DataDiscovery) |
|
@elasticmachine merge upstream |
There was a problem hiding this comment.
Code LGTM, great work 🎉 ! Tested locally and a-la-carte and works as expected 👍 . One thing I noted but that's not specific to this PR, once you saved there's no good way to check if a saved search stores the time or not. So actually, you've to open and see that it does. This is the same with dashboard. ideally we would have a indicator in the saved search list if a saved search is configured this way ... or a tag that's automatically assigned (now thinking of he who will bring tags to Discover aka @davismcphee )
davismcphee
left a comment
There was a problem hiding this comment.
Code changes LGTM, pulled and tested locally and works great! You'll make some users waiting five years very happy. Also I agree with @kertal about an indicator being a good idea, but also since it's the same in Dashboard I think it's good for now.
|
closing an issue with just four digits will not happen too often in the future, #9761. This is like resolving issues of your ancestors, let's spend a minute in silence ... or just don't write anything in slack for a minute |
|
Thanks for the reviews! Going to merge after #138388 |
…h-search # Conflicts: # src/plugins/discover/public/application/main/components/top_nav/on_save_search.tsx # src/plugins/discover/public/application/main/utils/persist_saved_search.ts # src/plugins/saved_search/public/services/saved_searches/types.ts
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
rudolf
left a comment
There was a problem hiding this comment.
The CI failure due to the field limit stems from the way esArchiver creates the .kibana index. It's hard to test these fixes without a PR like this one, so I decided to add a commit directly to this PR which will hopefully solve it.
| "routing_partition_size": "1" | ||
| "routing_partition_size": "1", | ||
| "mapping": { | ||
| "total_fields": { "limit": 1500 } |
There was a problem hiding this comment.
Here and in all the other mappings.json files I explicitly set the field limit to 1500. When FTR has an esArchive with the index name .kibana_$KIBANA_PACKAGE_VERSION_001 this creates an index with the current version number like .kibana_8.5.0_001. Because the index is already using the latest version number no migrations are applied and so the migration service will not update the field limit of this index.
So any time esArchiver creates such an "already migrated to the latest version" index we need to explicitly set the field limit. Because most tests don't delete the .kibana index once it exists, but merely "cleans" it by deleting all current saved objects, these archives can break other test suites that didn't even load the archive.
The alternative is to always delete the .kibana index for every test suite, but this is simply too time consuming and adds an incredible amount of time to each CI run.
|
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
Saved Objects .kibana field count
Unknown metric groupsAPI count
History
To update your PR or re-run it, just comment with: cc @jughosta |
azasypkin
left a comment
There was a problem hiding this comment.
Changes in SO/Spaces API integration tests LGTM.
* [Discover] Implement UI for storing time with a saved search * [Discover] Save time range data with a saved search * [Discover] Improve updating of values * [Discover] Restore time range after loading a saved search * [Discover] Add time range validation * [Discover] Add refresh interval validation * [Discover] Update how saved search gets restored * [Discover] Improve tests * [Discover] Update tests * [Discover] Improve type imports * [Discover] Update copy * [Discover] Fix types after the merge * [Discover] Update test name * [Discover] Fix types * [Discover] Update mapping * [Discover] Update mapping * Explicitly set field limit for .kibana_ esArchives Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Rudolf Meijering <skaapgif@gmail.com>
* [Discover] Implement UI for storing time with a saved search * [Discover] Save time range data with a saved search * [Discover] Improve updating of values * [Discover] Restore time range after loading a saved search * [Discover] Add time range validation * [Discover] Add refresh interval validation * [Discover] Update how saved search gets restored * [Discover] Improve tests * [Discover] Update tests * [Discover] Improve type imports * [Discover] Update copy * [Discover] Fix types after the merge * [Discover] Update test name * [Discover] Fix types * [Discover] Update mapping * [Discover] Update mapping * Explicitly set field limit for .kibana_ esArchives Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Rudolf Meijering <skaapgif@gmail.com>


Closes #9761
Summary
This PR adds support for storing the current time range and refresh interval with saved searches. Once such saved search is opened, it will restore the time filter. Embeddables on Dashboard won't use these data.
Checklist
Delete any items that are not applicable to this PR.