Draft: WIP: govern custom flow execution with role-based permission
What does this MR do and why?
Previously, the trigger_ai_flow permission was hardcoded to require Developer+ access.
With this change, we now check whether the user meets the minimum access level configured for the DAP Execute action. The implementation is feature flagged. When the FF is disabled, the default Developer role requirement is used can?(:developer_access)
Depends on: !213979 (merged)
Why are we targeting trigger_ai_flow permission for custom flow execution?
References
Many Triggers can be created to start Flows, however, there are only two available Triggers (
@mention and issue assignment) for External Agents.
Entry points for custom flow execution
These services are entry points that initiate the chain of services responsible for custom flow execution:
| Service | Description |
|---|---|
| EE::IssuableBaseService | Service invoked when Trigger is executed via issue/MR assignment |
| EE::Notes::PostProcessService | Service invoked when Trigger is executed via @ mention |
TODOs
-
Verify trigger_ai_flowis checked when a custom flow is executed in a runner job (remote execution), if applicable -
Verifytrigger_ai_flowis checked when a custom flow is executed in the IDE or CLI (local execution), if applicable- This is more so applicable to foreground execution being investigated in #582055 (closed).
trigger_ai_flowis checked during background/async execution
- This is more so applicable to foreground execution being investigated in #582055 (closed).
-
Update tests ee/spec/policies/project_policy_spec.rb
References
Feature flags
- GitLab.com:
Feature.enable(:dap_group_customizable_permissions, <top_level_group>) - Self-managed:
Feature.enable(:dap_instance_customizable_permissions, :instance)
How to set up and validate locally
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.