Email alerts link do not contain space id

[CruzMarcio]

Kibana version: 7.12.1

Elasticsearch version: 7.12.1

Describe the bug:

Email alerts sent by Kibana do not include the space URL on the "View alert in Kibana." link, causing the link not to work when the alert is not created on the default space.

Steps to reproduce:

1. Set the publicBaseUrl property on the kibana.yml file to the mail Kibana Url like "https://elk.company.com"
2. Setup an alert outside the Default space with an Email action.
3. When the email triggers, the URL will be: "https://elk.company.com/app/management/insightsAndAlerting/triggersActions/alert/..."
4. The link won't work as the alert is not on the Default space.

Expected behavior:

The link should contain the space ID on the URL like "https://elk.company.com/s/space1/app/management/insightsAndAlerting/triggersActions/alert/..."

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[pmuellr]

Not directly related, but happened to remember that I think we'll have an issue for customers who want to use our kibanaBaseUrl global context variable in actions, they'll want the space available as well. Which gets complicated since the default space has no "url prefix", where every other space has a /s/{space-name} prefix. And that may need to get URL encoded. So it seems like we will need a new context variable for "kibana space prefix", which you'd paste after the kibanaBaseUrl context variable, kind of thing. {{kibanaBaseUrl}}{{kibanaSpacePrefix}}/stuff-provided-by-user. I don't >think< we just always want to add the space prefix to the {{kibanaBaseUrl}} anyway, but there are other options like a variable kibanaBaseUrlWithSpacePrefix.

Not sure if this is mentioned in some other issue, I have a feeling it is, but couldn't find it ATM. Probably should be in a separate issue, if it really is an issue (I think it is).

And kinda brought it up to note that when we DO add the space to the link provided in the email, we probably want to url encode it with encodeURIComponent().

[mikecote]

@pmuellr ++ to what you said

I don't >think< we just always want to add the space prefix to the {{kibanaBaseUrl}} anyway, but there are other options like a variable kibanaBaseUrlWithSpacePrefix.

I was thinking about this. If we add the space id to kibanaBaseUrl, in theory, customers who already append the space id {{kibanaBaseUrl}}/s/space1/... would then get it appended twice now (breaking change) http://localhost/s/space1/s/space1.... So I guess I'm +1 on something like kibanaBaseUrlWithSpacePrefix and keep kibanaBaseUrl unchanged.

[ymao1]

And kinda brought it up to note that when we DO add the space to the link provided in the email, we probably want to url encode it with encodeURIComponent().

It looks like space ids can only contain alphanumberic characters plus - and _ so even if your space name is My\//&Space, the non-allowed characters get converted into dashes (my----space) so I don't think we need to use encodeURIComponent?

[pmuellr]

It looks like space ids can only contain alphanumeric characters plus - and _ so even if your space name is My//&Space, the non-allowed characters get converted into dashes (my----space) so I don't think we need to use encodeURIComponent?

Sorry for the late reply, but this came up in conversation yesterday as well. I believe that's correct, as long as the spaceid ends up with characters that don't need to be URL encoded, we wouldn't need to do an explicit URL encode on them. And alphanumerics and - do not need to be URL encoded, so I think we're fine with not doing URL encoding on them.