Preparation alerts and actions for feature controls

[mikecote]

No description provided.

[elasticmachine]

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

[pmuellr]

Where would this go? I guess in the SO's? Not clear to me that actions even need this - actions feel like they could span applications - eg, a general email action defined for a space.

And do we allow a "null" subType that might mean it doesn't fall under feature controls? I guess I'm wondering how someone might create an ad-hoc alert, not assigned a subtype for feature controls, for testing purposes, or something other "I'm not really an app" caller scenarios.

[mikecote]

Where would this go? I guess in the SO's?

This would go within the alert / action saved object until sub types is implemented (#47503). The migration to feature controls would be much easier to know which app owns what alert / actions and would be a simple move from attributes.subType -> subType as a migration.

We would also have to change the API that registers alert / action types to be in bulk and pass in their application id as well. Something like

plugins.alerting.registerTypes({
    appId: 'SIEM',
    alertTypes: [
        ...
    ]
});

And do we allow a "null" subType that might mean it doesn't fall under feature controls?

I think the subType would be relative to what alert / action type you select. That way if you don't have access to SIEM app, you don't have access to their alert / action types. In the future there could be more sub features per app including special actions. Just some thoughts.

[pmuellr]

The plugins.alerting.registerTypes({appId: 'SIEM',...}) bit makes it sound like it's somehow baked into the alert types/registry, but it then also shows up in the actual alert themselves ("This would go within the alert / action saved object").

In the case of a (near-)futuristic, general, reusable alert like a threshold alert, presumably that alert could be a "built-in", and so then couldn't provide an appId while being registered.

I suppose we could have any apps that want to, reuse that alert-type somehow, register it themselves with their own appId. So there might be multiple copies of the "threshold" alert type registered, but with different appId values.

I guess I'd say it doesn't feel right to bake this into alert type registration, does feel right to get the subType in the alert SO's somehow tho.

Whatever mechanism we use here, we'll likely want in the event log as well.

I'm wondering about actions also. Actions are a little weird because you really want to get the "feature-ness" from the alert that scheduled the action. Or at least take that into account. I'm not sure we have that kind of linkage today, but I've been thinking about it for the event log - when scheduling an action as part of an alert firing, we'll want to pass a reference to the alert into the action execution, to somehow reference both of those in the event log.

[mikecote]

I think you're right in regards to providing the appId on registration. It should be when you create an alert (API) as the alert belongs to an application at that time. And could be null or so if ever created through our UIs in the future.

[mikecote]

Removed from the description the following and renamed the issue to consumer instead of subType.

Should the sub type be the application itself (ex: SIEM) or the alert / action type itself?

We'll store the consumer and we already have the alertTypeId stored to satisfy feature controls.