[alerts] adds action group and date to mustache template variables for actions

[pmuellr]

resolves: #67389

Adds new variables to the existing set of variables that can be used in mustache templates to be used in action parameters when creating alerts.

• alertActionGroup - the action group associated with the alert scheduling actions
• date - the current date, in ISO format

Checklist

• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios

note that I left Documentation unchecked, but also added the needs_docs label per recent conversation on getting doc added - we'll need these new variables added to whatever documentation we have on these mustache variables

[elasticmachine]

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

[YulNaumenko]

LGTM

[gmmorris]

Works as expected, so LGTM, my only concerns is with naming (always the easiest problem, ey?):

Shouldn't alertActionGroup actually be alertInstanceActionGroup? or perhaps instanceActionGroup?

[pmuellr]

@gmmorris: Shouldn't alertActionGroup actually be alertInstanceActionGroup? or perhaps instanceActionGroup?

My vote is no.

Here's the full list of top-level names we make available as variables:

kibana/x-pack/plugins/alerts/server/task_runner/transform_action_params.ts

Lines 47 to 59 in c4543cc

	const variables = {
	alertId,
	alertName,
	spaceId,
	tags,
	alertInstanceId,
	alertActionGroup,
	context,
	date: new Date().toISOString(),
	state,
	params: alertParams,
	};
	return Mustache.render(value, variables);

Aside - this list always bugs me, I feel like maybe it makes more sense to have an alert object with the alert-prefixed variables in it, without the alert- prefix, kinda thing. A fight for another day :-)

We do have alertInstanceId, but that's basically alert + instanceId, so follows the "alert + property/well-known name" convention with the other names.

A search through the code base doesn't find any references to instanceActionGroup, not that that matters much - these names are intended for customers, not developers.

It's also a mouthful. I guess my main argument against it would be that it's already implied that you're operating on an instance at this point, so it's not really needed. And it's a mouthful :-)

I can be convinced otherwise :-)

[pmuellr]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: f20b104

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
triggersActionsUi	1.4MB	1.4MB	+460.0B

History

• 💚 Build #87996 succeeded c4543cc
• 💚 Build #87757 succeeded d515748ed799ba7f72a631f6eb5f193e37d067eb
• 💔 Build #87400 failed e34bd5a94df6b7fbbd64c14920839e650d35961e

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream