-
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
[Search Sessions] Reload action on management screen needs refinement #89327
Comments
Pinging @elastic/kibana-app-services (Team:AppServices) |
I like option 1, but since that's not possible, here's a 3rd option into the mix: We remove this capability from the management view and they can only 'reload' the session from the popover on the dashboard. This would avoid the modal confirmation and perhaps make it clearer that I am running a new search session. We will also have 'Rename' in the management overflow menu, so maybe it's also nice to trim off an option here as we add a new one. |
@mdefazio, if a session is expired or canceled, the only way to re-run it is from the management view, as |
@Dosant do you think it would be clearer if the action was called |
Yes, I think I like it more! I also think:
|
Agreed to just remove the |
Part of #61738
Follow up on #61741
Currently we have three actions per search session on management screen:
Both "cancel" and "extend" have dialog that explains what is going to happen.
Reload though behaves differently:
It just navigates to the search session origin app and start a new search (a new search session) with the original state (time range/filters/query).
Without any additional explanation or confirmation, It seems that just navigating away could be very confusing because there are no ties or context to the session we are going to "reload".
We also not actually reading the search session, we just starting a new one from the same application state that we started an original one. So maybe the wording also should be changed.
Another possible reason for the confusion is the difference between "restoring" and "reloading" the session is a time range. When we "restore" a session we force the absolute time range. Currently, the original and augmented application's time range is implicit and maybe we should emphasize it somehow in mgmt UI. But this is probably a different issue.
cc @mdefazio, @lizozom
The text was updated successfully, but these errors were encountered: