[Alerting] Control Alerts Management via feature controls & privileges

[gmmorris]

Summary

Closes #69665

This PR removes the alerting and actions ui privileges (alerting:show, actions:show, etc...) and instead relies on the standard Kibana feature control model to decide whether management displays the Alerts Management section under management.

Dev Notes

If you want your plugin to grant a user access to the Alerts Management section you need to specify it under management in your feature configuration.

You do so by adding this sections:

management: {
    insightsAndAlerting: ['triggersActions'],
},

There are 3 places where you can specify it:

1. Directly on the feature. When security is disabled, this grants access to every role who's granted access to the Feature via Feature Controls. When security is enabled, this specifies that the feature has access to this management section and is required before you can grant this to a specific role.
2. Under the all privilege. When security is enabled, this grants access to every role who's granted the all privilege to the Feature via Feature Controls
3. Under the read privilege. When security is enabled, this grants access to every role who's granted the read privilege to the Feature via Feature Controls

This means that, likely, you'll have to specify this in 3 places in your plugin to cover all 3 scenarios. This is more verbose than what we had before, but it is the correct way to do it (to align with the rest of Kibana) and it means the Triggers and Actions plugin no longer needs to know about each plugin that wants to gain access (which means we can more easily support future alerting usage).

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser
• This was checked for cross-browser compatibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[pmuellr]

code LGTM, but also want to load it up and try it live, and haven't yet. Leaving as a comment for now, till I do (today or tomorrow).

[pmuellr]

I'm curious - we don't have one of these stanzas for actions, but I'm guessing we can only registerProvider() in one place. What happens if security is enabled, alerts is disabled and actions is enabled? Thinking about a future-Kibana that uses actions in other scenarios besides alerts ...

[gmmorris]

Oh, actually, this might be an oversight.
@legrego do we still need this?

[gmmorris]

Hmm I've checked and removing this causes it to appear to unprivileged users.
I think this PR might not be ready yet and might require some work by Security.

[legrego]

Thanks for the ping - we still want this in place, at least for the time being. There is a bug in Feature Controls where features can't successfully "register" their management sections, because the features plugin isn't accounting for them when building the canonical set of Capabilities. The workaround is for plugins to provide this capability manually, until we can update the Features plugin.

This provider does not influence or control any sort of access management. It merely defines the boolean flag (with the correct default value of true) so that it may be controlled by Security/Spaces as needed.

FWIW, we can remove this once #67791 merges, as this PR updates the features plugin to respect management sections.

[pmuellr]

curious there's no else clause for this if. This function appears to just update state after loading the alerts, and that doesn't need to be done if there's nothing to view. But then wondering if the user will end up at with an empty view, or perhaps even gulp a view which suggests to create a new alert :-). Guessing this case is covered already, just not clear from looking just at this function, will test it live.

[gmmorris]

Correct, it's handled in the render itself - which is why I would like us to split this file down into like 4 or 5 files - it's way too big and hard to follow.

[gmmorris]

But that can be a separate PR

[sorenlouv]

APM changes lgtm

[YulNaumenko]

LGTM. Tested live for different users with variety of alert/action role settings, and everything work as expected.

[pmuellr]

loaded up the PR and took it for a spin - works as advertised

[gmmorris]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

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

Build metrics

@kbn/optimizer bundle module count

id	value	diff	baseline
triggers_actions_ui	151	-1	152

async chunks size

id	value	diff	baseline
triggers_actions_ui	725.8KB	+12.2KB	713.6KB

page load bundle size

id	value	diff	baseline
triggers_actions_ui	262.8KB	-4.1KB	266.9KB

History

• 💚 Build #63604 succeeded 7c51753
• 💔 Build #63273 failed 8545f64
• 💚 Build #63220 succeeded c44b626
• 💛 Build #62715 was flaky e284ccf
• 💛 Build #62706 was flaky efbc59a

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

[justinkambic]

Uptime changes LGTM

I pulled this branch and ran it, seemed to work ok 👌

[FrankHassanabad]

LGTM

[weltenwort]

infra plugin changes LGTM

[gchaps]

@gmmorris For future PRs with the release_note:plulgin_api_changes, please use the title "Dev Docs" instead of "Dev Notes" in the summary. Otherwise, the script won't pick up your write-up.