Alert framework level license check

[mikecote]

Similar to #54946, we should implement license checks for alert types. Some solution teams (ex: maps) are planning to have alert types available only in higher licenses than basic.

Some remaining questions:

• Should there be a minimum license required for 3rd party alert types? similar to action types.

Current issue was spliced to the next set of sub issues which are corresponding to the steps of the implementation:

• 1. [Alerts][License] Define minimum license required for each alert type. #84954

• 2. [Alerts][License] Add license checks to alerts HTTP APIs and execution #85102

• 3. [Alerting UI][License] Disable alert types in UI when the license doesn't support it. #85282

• 4. Follow up issues:
  [Alerts][License] Advanced handling of the execution alerts with the higher order alert type license.  #85634
  [Alerting UI] Add licensing related enhancements of existing UI. #85640
  [Alerts][License] Bypass the license check for a pre-configured alerts. #85638

[elasticmachine]

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

[mikecote]

Closing this as it no longer seems to be a request at this time (map based alerts are in basic).

[mikecote]

cc @arisonl

[arisonl]

@mikecote with regards to the user experience @alexfrancoeur is working on a strategy for consistently promoting features across Kibana. For the time being the UX we offer for connectors (visible, disabled, greyed out) is a good way forward for higher license alert types.

[YulNaumenko]

There are a couple of options how the framework should behave during the Alert execution with alert type which is under the higher license that the user currently has:

1. Disable alerts with the higher license alert types. After upgrade, user will be able to enable them.
2. Constantly throw the console errors with Forbidden error (not user friendly)
3. Any other thoughts?

[pmuellr]

• "Disable alerts with the higher license alert types" sounds right.
• "Constantly throw the console errors with Forbidden error" is not good :-). Could we arrange to log a console error when we disable the alerts, just once?

Any other thoughts?

It would be nice to provide some text on why these are disabled in the alerts list and in alert details.

[mikecote]

Option 1 looks good.

It would be nice to provide some text on why these are disabled in the alerts list and in alert details.

If something is done here, it could also be leveraged for import / export. It could track a reason like disabledReason: 'user' | 'import' | 'license'. Where we can display a user friendly message in the UI and in the future we add import as a value.

[YulNaumenko]

Option 1 looks good.

It would be nice to provide some text on why these are disabled in the alerts list and in alert details.

If something is done here, it could also be leveraged for import / export. It could track a reason like disabledReason: 'user' | 'import' | 'license'. Where we can display a user friendly message in the UI and in the future we add import as a value.

Sounds right for me. Do you mean here like exposing a separate alert property disabledReason in addition to enabled ?

[mikecote]

Sounds right for me. Do you mean here like exposing a separate alert property disabledReason in addition to enabled ?

That is an idea 🙂 I'm sure there may be better ways for this. As long as it could scale for future scenarios.

[pmuellr]

We don't have a separate field for this for actions though, do we? The reason calculated as needed? Seems preferable to having a separate field, if that can be made to work.

[mikecote]

We don't have a separate field for this for actions though, do we?

Correct, we don't have a field for this at this time.

[mikecote]

Some further chat about disabling alerts vs pre-configured alerts (#84997 (comment)).

Just to add to the conversation, Stack Monitoring also has the concept of certain alerts being only available in gold/platinum; however, we are currently creating these alerts "out of the box" (since this concept doesn't exist yet, we are creating these when the user first visits the Stack Monitoring UI) and I'm worried about applying rules for alert creation for a data point that can change over time. For example, if they are on the Basic license when they first visit the Stack Monitoring UI, then upgrade to Gold and don't revisit the Stack Monitoring UI, any gold-gated alerts will not exist. This might be something to consider when implementing #59813 cc @mikecote

@chrisronline good point. I think for pre-configured alerts, we should bypass the license check for those and handle it differently (ex: execution time). There's ongoing discussion about how we should handle expired licenses and the existing alerts. It seemed disabling the alert was the best option, but maybe not? thinking about your use case where you'd just want the alerts to "resume". This may be the same expectation with other alerts. cc @YulNaumenko