## Summary This issue implements the core `Execute` permission for DAP (Duo Agent Platform) role-based permissions. We will enable the central permission-checking mechanism that determines whether a user can execute agents and flows based on their role and configured permissions. This issue only includes preparation for further issues like the following: - https://gitlab.com/gitlab-org/gitlab/-/issues/578553+ - https://gitlab.com/gitlab-org/gitlab/-/issues/578554+ - https://gitlab.com/gitlab-org/gitlab/-/issues/578555+ - https://gitlab.com/gitlab-org/gitlab/-/issues/578563+ ## Background As part of the DAP role-based permissions epic (#19743), the `Execute` permission is the most critical functionality that controls user access to execute: - Built-in flows - Agents in Agentic Chat - Custom agents and flows The permissions will be based on existing policies, abilities, and dynamically configurable permissions. They will be used across all DAP execution points to enforce role-based access controls. ## Requirements ### Permission Service Implementation We want to prepare the extension of policies and abilities around DAP. For that, we might want to create a `DapPermissionService` with the following core method. This method will then be used for abilities that get access via `Ability.allowed?` or `current_user.can?`. ```ruby def can_user_perform_action?(user, namespace, action) # Permission resolution logic end ``` ### Permissions Logic Responsibilities - [ ] **Permission Resolution**: Determine effective permissions for the user in the given context - [ ] **Role Evaluation**: Check user's roles against configured permission settings related to the current namespace (project and group) - [ ] **Context Handling**: Support both instance-level and namespace-level permissions ### Permission Logic #### Resolution Order 1. Check namespace-level permissions on GitLab.com. 2. Check instance-level permissions of Self-Managed. ### Technical Implementation - [ ] Prepare the extension of existing abilities and policies. - [ ] Add default values for the different role-based permissions. - [ ] Potentially outsource the permissions logic to a separate `DapPermissionService` class ## Service Interface ```ruby class DapPermissionService def self.can_user_perform_action?(user, namespace, action) # Returns boolean indicating permission end def self.user_permissions(user, namespace) # Returns hash of all permissions for user end private def self.resolve_permissions(namespace) # Permission resolution logic end def self.user_roles(user, namespace) # Get all user roles in context end end ``` ## Acceptance Criteria - [ ] We leverage existing policy and ability conventions - [ ] We potentially outsourced role-based permissions logic to a `DapPermissionService` that is reused by the policies and abilities - [ ] We support instance-level and namespace-level permissions - [ ] Comprehensive unit tests cover all permission scenarios - [ ] Integration tests verify service behavior with real data ## Related Issues - Parent Epic: #19743 - \[Backend\] Role-based permissions controls for DAP - Depends on: #578551 - Role-based permissions DAP - Model implementation - Related: #578553, #578554, #578555, #578563 - Execute permission integrations ## Notes This service will be the foundation for all other DAP permission enforcement issues. It must be robust, performant, and well-tested as it will be called frequently across the platform.