[RAC] Use alerting framework to check alert permissions in the UI

[mgiota]

(title to be better defined)

📝 Summary

At the moment Alerts table UI needs to make use of the producer value to determine if workflow status options should be visible to the user or not (Mark as Acknowledged and Closed). In case the value of the consumer is alerts (this means the rule was created through Stack Management and not through the respective Observability App), then we use the value of the producer to determine alert permissions. In any other case we use the consumer. https://github.com/elastic/kibana/pull/110167/files#diff-f9d2565b68bb75d711c69a2d1c21a6e9c4ced3494068fee60845b93e4eca1895R213 and https://github.com/elastic/kibana/pull/110167/files#diff-f9d2565b68bb75d711c69a2d1c21a6e9c4ced3494068fee60845b93e4eca1895R309

Producer refers always to wherever the rule type is registered in the code (apm, logs, infrastructure etc). Consumer is where the rule instance was created by the end user (alerts, apm, logs, infrastructure etc). All rules of a given rule type will always have the same producer value. But they can have different consumer values based on where they are created in the UI. #107857

Above consumer/producer logic is an implementation detail and shouldn't be exposed to the UI, because it increases the likelihood of bugs. Alerts permissions logic already exists in the alerting framework and should be used to determine the visibility of UI elements. UI shouldn't duplicate this logic as it currently happens in above mentioned lines of code.

✔️ Acceptance criteria

• Check if the existing alerting framework implementation has a method that gives back the alert permissions https://github.com/elastic/kibana/blob/master/x-pack/plugins/alerting/server/authorization/alerting_authorization.ts. If not implement a public method that returns alert permissions
• Timelines plugin should ask the alerting framework for the read/write permissions of each alert (it most probably does it already)
• Timelines search strategy should send the alert permissions of each row as part of the response.
• Alerts table UI should check the returned alert permissions of each row to determine if some UI options will be visible or not.
• Existing logic in the Alerts table UI that checks if consumer value is alerts should be deleted

[banderror]

I'm not aware of the implementation on the Observability side and can be mistaken about all the dependencies, but we have code in rule_registry that implements RBAC and I'd guess it can be related to this issue:

• x-pack/plugins/rule_registry/server/alert_data_client contains an implementation of RBAC-aware methods built on top of the AlertingAuthorization
• x-pack/plugins/rule_registry/server/routes contains routes that implement RBAC-aware read and update operations

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)

[mgiota]

@banderror Thanks for this info! It looks promising. I will look into the existing methods and see if I can reuse one for our needs or add a new one.

[CoenWarmer]

@simianhacker is this something we still want to do, and if we do, is this part of AO or the Alerting Framework?

[simianhacker]

Looks like it's outdated