[Response Ops] Rules navigation appears if user has access to Actions and Connectors but no rule types

[ymao1]

When we have a role that gives a user access to Actions and Connectors but no alerting rule types, the user is still able to see Rules in the Stack Management navigation. Going to the page will show No access but I believe that this menu item shouldn't show up at all for this role.

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[umbopepato]

It looks like the capabilities that result from such a role configuration include triggersActions:

which is associated to the Rules app in the ManagementSection and thus makes the page visible:

@mdefazio should we remove that capability from Actions and Connectors?

[mdefazio]

Likely need others input here, but if I'm understanding this...
Allowing Actions and Connectors, enables triggersActions, which also enables Rules behind the scenes (does it this still show as 'None' even if triggersActions is true?

So what happens when access to Stack Rules is allowed? Not saying it should, but does this enable Actions and Connectors via triggersActions as well?

While I should likely know this, when am I using Actions and Connectors outside of Rules or Cases? There was always the intention, but are they used elsewhere?

Looking at the screenshots, should this config only effect triggersActionsConnectors? Enabling Stack Rules would then effect triggersActions...but this is me likely not understanding.

And since we're here...shouldn't Maintenance Windows be tied closer to the triggersActions? Since you would be stopping actions by creating a maintenance window

[umbopepato]

does it this still show as 'None' even if triggersActions is true?

It does, and when inspecting the role in http calls only actions: ["all"] is present under kibana.

So what happens when access to Stack Rules is allowed? Not saying it should, but does this enable Actions and Connectors via triggersActions as well?

It does not, the only enabled feature is stackAlerts: ["all"].

To my (still very limited) understanding, the mapping between privileges and capabilities in this case seems to be:

Privilege display name	Privilege id	Capability id
Actions and Connectors	actions	triggersActionsConnectors
Stack rules	stackAlerts	triggersActions