[ResponseOps][Alerting] Hiding all features in a space causes rules to stop running

[doakalexi]

Resolves #144638

Summary

Removes logic that prevents rules from running when all features in a space are disabled.

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

To verify

• Create an alerting rule
• Go to the spaces page, and disable all features in the space
• Look at your terminal to see the alerting rule still running and no errors

[elasticmachine]

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

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: dd102be

Metrics [docs]

Unknown metric groups

ESLint disabled in files

id	before	after	diff
osquery	1	2	+1

ESLint disabled line counts

id	before	after	diff
enterpriseSearch	19	21	+2
fleet	59	65	+6
osquery	108	113	+5
securitySolution	441	447	+6
total			+19

Total ESLint disabled count

id	before	after	diff
enterpriseSearch	20	22	+2
fleet	67	73	+6
osquery	109	115	+6
securitySolution	518	524	+6
total			+20

History

• 💔 Build #88599 failed 6edacd7
• 💔 Build #88501 failed 851878d
• 💔 Build #88462 failed cb66e37

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

[ersin-erdal]

LGTM.
Tested locally, works as expected.

[ymao1]

This change also makes it so that a user with access to a space where all features are disabled can still use the alerting API to list all rules from this space that were created before the features were disabled. I'm assuming that's ok? cc @mikecote

[mikecote]

This change also makes it so that a user with access to a space where all features are disabled can still use the alerting API to list all rules from this space that were created before the features were disabled. I'm assuming that's ok? cc @mikecote

If ^^ is true, we can't have the alerting API leak rule information for users who don't have access to the feature.. We might have to revisit the approach and revert / fix the change.

[ymao1]

This is what I tested:

• Create a rule in the default space
• Turn off all features for that space
• Create a role for the default space that doesn't have access to any rule types
• Create a user with this role
• Log in as this user. Can't navigate anywhere in the UI
• Navigate to https://localhost:5601/api/alerting/rules/_find and see the rule that I created in step 1, even though I shouldn't have access to any rule types.

Would be great to verify that others see this behavior as well.

[pmuellr]

TBH, I was kinda confused by this issue, because I thought - well, if they don't have access to the features, they probably shouldn't be able to run rules.

Was the thinking here resilience? To make sure the rule would keep running if someone accidentally made a bunch of feature changes?

Especially given the unintended consequences ^^^, I think we should revisit. To me, ideally the rule would error out when run, and surface an actionable message to the user in the UX on what happened.

[mikecote]

The way I see it with my thinking is; when rules are created, they take a snapshot of the user's privileges in time and will keep running using those. So if the privileges or user roles have changed, the rule shouldn't be impacted by them and still run as what the snapshot encapsulated when the rule was created / updated.