Role-based permissions DAP - Model implementation

Summary

This issue implements the database model and backend infrastructure for DAP (Duo Agent Platform) role-based permissions. This is the foundational component that stores and manages permission configurations for both instance-level and top-level group settings.

Background

As part of the DAP role-based permissions epic (#19743 (closed)), we need to create a flexible model that allows administrators to configure which roles can perform specific DAP actions. This model will support two permission types:

• Manage: Create, duplicate, edit, enable, and delete agents and flows.
• Execute: Execute agents and flows in the context of projects.
• Enable on projects of agents and flows.
  • Enable on groups is hardcoded to owner+

Requirements

Database Schema

Extend existing tables ai_settings and namespace_ai_settings to store role-to-permission settings:

Column	Type	Null	Description
minimum_access_level_execute	integer	false	Access level (guest, planner, reporter, developer, maintainer, owner)
minimum_access_level_manage	integer	false	Access level (maintainer, owner)
minimum_access_level_enable_on_projects	integer	false	Access level (maintainer, owner)

Model Implementation

• Add permission attributes to Ai::Setting for instance-level permissions
• Add permission attributes to Ai::NamespaceSetting for group-level permissions
• Add validation ensuring Execute permission is limited to guest+ roles
• Add validation ensuring Manage permission is limited to maintainer+ roles
• Add validation ensuring Enable (for projects) permission is limited to maintainer+ roles

Old plan

• Create Ai::RolePermission model
• Implement and permission enums
• Add uniqueness constraints for namespace_id

Technical Considerations

• The table ai_settings and namespace_ai_settings could hold the two permissions manage and excute, but we create a separate table for the permissions. Reasons are the following:
  • Separation of concerns: These two tables are for toggles and configurations and not for roles.
  • Future flexibility: Permissions may evolve independently; it will be easier to adapt the roles without polluting AI settings, and it will create clear ownership of the feature.
• Support both instance-level (namespace_id = NULL) and top-level group settings.
• Ensure backward compatibility with existing hardcoded permissions during transition.
• Lazy backfill by using default values when there is no change in the permission yet made by the customer

Acceptance Criteria

• Tables are for the instance and for namespace are updated with new permission attributes
• Database migration creates the new attributes with proper constraints
• Unit tests cover model validations and associations
• Database schema documentation is updated

Old criterias

• Default permissions are seeded to match current behavior
• Ai::RolePermission model is implemented with validations
• Model is accessible through Ai::SettingandAi::NamespaceSetting``

Related Issues

• Parent Epic: #19743 (closed) - [Backend] Role-based permissions controls for DAP
• Related: #578270 (closed) - Permissions model suggestion for DAP
• Related: #578370 (closed) - Collect all codebase locations that need to consider DAP role-based permissions

Notes

This model will be used by other DAP permission issues to enforce role-based access controls across the platform.