📓 Summary

Based on the research made with #172469, we will support data view selection directly from Logs Explorer for certain data views focused on a logs experience.

✔️ Acceptance Criteria

• The following data views, when selected, should keep the user on the Log Explorer:
  • Anything that starts with logs-: e.g. logs-foo-bar.
  • Anything that starts with filebeat-, winlogbeat- or auditbeat-. We can later add also logstash-.
  • Any CCS prefix to one of the above patterns should be supported.
• Any data view matching the above criteria...
  • should load the related additional fields for the stored data view.
• Any data view NOT matching the above criteria...
  • should display an icon to signal that the data view is not logs-related.
  • should display a confirm prompt that tells the user about the performed action intent (go to discover).
  • should redirect to Discover as currently does when selected.
• When a user refreshes the page, it should correctly restore the selected data view.

🎨 Design

🎨 Logs-only data views design

💡 Implementation hints

• We can treat it as an allowed list of patterns (strings or regexp) to match the target data views we want to browse in LogExplorer. There is already a state machine to control the data views retrieval and sorting, we could probably apply this new piece of logic here.
• As an initial approach, we will derive a new ad-hoc data view starting from the persisted one. This means we'll need to add a lookup step to retrieve the data view by its ID when we should restore it on refresh/navigation.
  The log explorer controller state machine is the place to look for this step.