-
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
[Logs UI] [WIP] Prompt for a data view when log source not configured #98277
Comments
Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui) |
Notes from discussion with @weltenwort Background:This issue was to be the last step in our planned migration to only using Data Views to configure the Logs UI, deprecating the options to use plain index names. However, we received feedback from users that this would create a barrier to usage due to the fact that you need more permissions to create a Data View (in the case that one hasn't already been used). This means that the usually read only Analyst role would have to rely on someone with higher level permissions to setup the UI for them, an admin user which might not be likely to enter the Logs UI per space that is being created to configure the source. As a result of this we're back peddling a bit on this plan. We will continue to support the plain index names option (which plays well with our embeddable/internal source configuration strategy). However, we still want to nudge user into the path of using Data Views since it offers us benefits such as linking into other Kibana apps as well as creating column from Runtime Fields. Next steps:1. Add support for opting out of Data Views source configuration 2. Add dialog to inform users about configuration options a) For the Write privilege user b) For the Read privilege user Once Step 1 is complete, we will revisit this issue to update the ACs in line with Step 2. Future plans:In the future we want to integrate the Data View creation flyout in the component used to configure the Source Configuration, to reduce the number of page links out of Logs UI to configure it. At some point we also need to consider how the "prefer Data Views" path affects our embeddable use cases. Today they can specify the config by an ID but they might want options to specify it with plain index names or Data Views to allow further linking into other Kibana apps. We also need to then solve for the use case of upgrading a source configuration to affect both the embeddable and the log stream UI. This might also be solved by using Transient Data Views once they land. We also need to consider the future where we might have per user configs in some kind of middle state before it is saved. Both for users who are trying things out before committing the changes, but also for Read privilege users that still want to modify their own experience locally. Finally, there was an idea of creating a workflow where a Read privilege could submit a Data View creation request for Write privilege user approval, allowing the Read user to define the configuration as they want but using the Write user's credentials to execute the request. More info here #119887 |
One more note on this, an option that we can consider is to use the Kibana system user to create a default Data View per space. This is what both APM and the Security solution does to make at least one Data View available for usage, the user can still create their own if they have the right permissions. Perhaps it's about naming of the Data View and of informing the user that this has been created due to its absence. |
A note on the Saved Object that gets saved: When creating a Source Configuration, either via the Metircs UI or the Logs UI the Saved Obejct that is stored contains configuration for both apps, using the defaults for the "other" app. This means that if we wanted to prompt for setup in the Metrics UI, but the Logs UI has already been configured we would not be able to detect the "fallback" state anymore. Yet the user has not explicitly configured the Metrics UI. We can keep supporting reading from the old shared Saved Object, and only change so that we write to new split Saves Objects. |
@weltenwort / @miltonhultgren should we close this ticket in lieu of the other source config work now being started? |
No, it's step 2 of the proposed task breakdown in the epic. |
We should likely show this prompt on all Logs UI pages so that the user does the configuration before using any page. |
The ACs intentionally don't limit this to only the logs stream page. There's probably not harm in showing it on all logs UI pages. |
Updated description and title to say "data view" instead of "KIP." |
Pinging @elastic/obs-ux-logs-team (Team:obs-ux-logs) |
📝 Summary
Even though log sources can be configured based on a data view in #92650, the default is still an index name reference. Because we can't assume the existence of any specific data view, the Logs UI can't work without an explicit choice being made by the user. This aims to introduce a quick data view selection prompt when the user visits an unconfigured log source.
part of #120920
✔️ Acceptance criteria
🎨 Mock-ups
🔭 Outlook
Once a data view creation flyout as described in #67711 exists, it could be used here to avoid the need to leave the Logs UI when lacking a data view.
The text was updated successfully, but these errors were encountered: