[Log Explorer] Add specialized locators

[weltenwort]

📓 Summary

The Discover locators will already include a key to choose the customization profile. In order to support passing data specific to the log explorer profile in a type-safe way, though, we could implement custom locators that wrap the Discover locator.

• 🛑 blocked by: [Logs+] Implement Logs Dataset selector #159907
• ⏩ superseded by: [Explorer] Add Explorer app locator #164995

✔️ Acceptance criteria

• There is a locator that accepts the same arguments as the Discover App locator except that...
  • the properties savedSearchId, dataViewId, indexPatternId, dataViewSpec, Profile are removed
  • properties to specify the integration name and the data stream name are added
  • properties to indicate the origin of the navigation are added if it takes places as part of a workflow
• The origin value is a union of objects with...
  • an id to describe the workflow and/or step that initiated the navigation. This is the tag of the union.
  • any properties appropriate for the given id, might be none at all.
• Valid origin ids (for now) are:
  • new-integration without additional properties: for use at the end of the of an on-boarding workflow
  • new-route with properties for the source integration name and source data stream name: for use at the end of a re-routing workflow
• The targeted profile is always the log explorer profile.
• Wire up the usage of the new locator to the Explore Logs Button at the end of the onboarding flow.

💡 Implementation hints

For inspiration/illustration purposes:

type DiscoverAppLogProfileLocatorOrigin =
  | {
    id: 'new-integration';
  }
  | {
    id: 'new-route';
    sourceIntegrationName: string;
    sourceDatastreamName: string;
  }

[elasticmachine]

Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI)

[yngrdyn]

The integration id could be enough @weltenwort?
@gbamparop, @ogupte do you foresee which params we would need to pass to the locator?

[weltenwort]

An integration could have multiple data streams of type logs. Would the on-boarding workflow be able to also provide the data stream name or does the log explorer profile need to choose one (randomly)?

[gbamparop]

@gbamparop, @ogupte do you foresee which params we would need to pass to the locator?

When the onboarding succeeds and we have identified that logs are being ingested (issue), there will be a success message in Discover. This seems to need an additional parameter.

[weltenwort]

there will be a success message in Discover

@gbamparop indeed, I was thinking that it could derive the correct message from the origin id that is passed. Does that make sense?

[gbamparop]

@gbamparop indeed, I was thinking that it could derive the correct message from the origin id that is passed. Does that make sense?

Is the idea to have a new prop as per below?

any properties appropriate for the given id, might be none at all.

There's also the feedback link in Discover.

[weltenwort]

If the feedback link would change dynamically based on the specific on-boarding workflow we might need to pass a specific property. But if the feedback link is always the same the log explorer can show it whenever the user comes here with a new-integration origin.

[gbamparop]

If the feedback link would change dynamically based on the specific on-boarding workflow we might need to pass a specific property. But if the feedback link is always the same the log explorer can show it whenever the user comes here with a new-integration origin.

@grabowskit will we have more than one feedback forms?

[mohamedhamed-ahmed]

@weltenwort As agreed we will keep the implementation of the DiscoverAppLogProfileLocatorOrigin interface for later as it is not going to be used at the moment. I also update the description as agreed.

[weltenwort]

• ℹ️ Due to the decision to build the log explorer as a separate app, this issue has been superseded by [Explorer] Add Explorer app locator #164995.