Ability to generate URLs in alert action parameters

[mikecote]

We'll need to eventually allow users to build URLs within emails, slack messages, etc that point to Kibana. In order to do this, we'll need some functions or pre-defined variables within the mustache templates to help building URLs back into the application.

Currently blocked by #45815.

[elasticmachine]

Pinging @elastic/kibana-stack-services (Team:Stack Services)

[pmuellr]

I think we would eventually want a link back to the original Kibana home page, or perhaps even a home page for a space, if that's all we could get if we end up getting #45815. Unfortunately, we'll need to do a little design work on where that would appear in the "context" passed to the action. We probably would want an entirely new object passed in, I'm thinking.

[mikecote]

Adjusting the Mustache template values may be all we need. This is what we do currently: https://github.com/elastic/kibana/blob/master/x-pack/legacy/plugins/alerting/server/lib/transform_action_params.ts#L29. We could either keep adding flat values to allow <a href="{{kibanaUrl}}/management/alerting/..." /> style URL building.

[peterschretlen]

See also: #25247 which longer term may provide a solution

[bmcconaghy]

Related to #25247

[pmuellr]

Per #64370, would be nice to generate links to the alert details page and the alert management page:

• ${kbn-url}/app/kibana#/management/kibana/triggersActions/alert/${alert-id}
• ${kbn-url}/app/kibana#/management/kibana/triggersActions/alerts

[mikecote]

It looks like #25247 is now resolved, we should see if that suits our uses cases.

[mikecote]

The pluggable URL service will be available on the server side once #59453 is completed.

[mikecote]

I had a chat with the App Architecture team last week. The work done for URL generators (#59453) is mostly for capturing / migrating app state and deep links. What we need is mostly the base URL of Kibana.

After chatting with @kobelb, the best approach seems to be the following:

• Work with window.location by default to capture the URL on the browser side and make it work with alert action variables
• Add an optional kibana.yml setting which can override the ones we get from the window.location via alert action variables

The R&D part here would be allowing the optional kibana.yml setting to overwrite the URL passed from the UI. Probably via mustache templates if a helper can do it or something..

EDIT: We may not require #45815 anymore.

[pmuellr]

Work with window.location by default to capture the URL on the browser side and make it work with alert action variables

I don't fully understand how this would work. Is the idea we would capture the URL when an alert is created to save the URL so we can inject it into action parameters? This obviously won't work for alerts created via curl invocations, eg. Where is saved? In the alert? Which is then problematic when servers migrate to new names.

I like the idea of somehow using window.location to help validate a kibana.yml config value, but not quite sure how that might work. We could maybe have the main alerts/connectors page test the value and present a warning if the config value didn't match what the browser is using - presumably without leaking the config setting (in case it's a security issue?). It would actually be nice for this config setting to be editable within Kibana itself, as we could provide the window.location value as the default value to use, and additionally warn if it doesn't match the config. Not sure where we'd store it tho.

Lastly, @matschaffer noted offline that cloud already passes the kibana URL around in various internal configs already - we'll certainly want to take advantage of that so that cloud deployments will be zero-config for this setting. We'll have to work with cloud folks to figure out the best way to pass this in.

[matschaffer]

@pmuellr just for clarification, the internal configs I sent earlier are just for specific deployments.

But yes, ideally we should be able to link back to the kibana that generated any alert.

We should probably keep this configurable in the event of people using https://github.com/bitly/oauth2_proxy or a similar proxy for typical kibana access.

[matschaffer]

Also window.location seems like it might preclude managing the alert via git (which we do exclusively), so that solution sounds less than ideal.

[pmuellr]

I'm typically thinking about this as being able to provide a link to the alert details (eg, in a slack/email message), but even better for solution-based alerts (most of them!), it would be nice to have a link to a solution page relevant to the alert.

So it seems like we'll need to think about alerts providing an array of links, which could then (somehow) be rendered into relevant action parameters. We can provide a "free" link to the alert details, along with whatever the alert provides.

For index threshold, it would be nice to provide a link to a discover page that showed "relevant" documents, used the alerts window / interval for bucketing, etc.

[pmuellr]

Also note - it would probably be useful to provide these links within the alert details page as well. I suppose that could mean we may need to provide two URLs for a particular Kibana page - one that we use in email / slack / etc, and another that would be used to navigate to the same page, but staying within Kibana so no page reload would occur. I'm assuming those two "urls" could be different.

[mikecote]

Moving from 7.x - Candidates to 7.13 after the latest 7.x planning session. If we get time, we will implement this.

[pmuellr]

proof of concept in this PR