Lightning.Policies.Sandboxes (Lightning v2.15.16)
View SourceThe Bodyguard Policy module for sandbox project operations.
Sandboxes have different authorization rules than regular projects:
- Sandbox owners/admins can manage their own sandboxes
- Root project owners/admins can manage any sandbox in their workspace
- Editors (and above) on the root project can merge sandboxes
- Editors (and above) on the parent project can provision sandboxes
- Superusers can manage any sandbox anywhere
Summary
Functions
Authorize sandbox operations based on user role and project hierarchy.
Bulk permission check for multiple sandboxes to avoid N+1 queries.
Types
Functions
@spec authorize( actions(), Lightning.Accounts.User.t(), Lightning.Projects.Project.t() ) :: boolean()
Authorize sandbox operations based on user role and project hierarchy.
Authorization Rules
:delete_sandbox and :update_sandbox
User can perform these actions if they are:
- Superuser (can manage any sandbox)
- Owner/admin of the sandbox itself
- Owner/admin of the root project (workspace)
:provision_sandbox
User can create sandboxes if they are:
- Editor/admin/owner of the parent project they're creating the sandbox under
:merge_sandbox
User can merge a sandbox into a target project if they are:
- Editor/admin/owner on the target project
- Superuser
Parameters
action- The action being attempteduser- The user attempting the actionproject- The sandbox project (for delete/update), parent project (for provision), or target project (for merge)
@spec check_manage_permissions( [Lightning.Projects.Project.t()], Lightning.Accounts.User.t(), Lightning.Projects.Project.t() ) :: %{ required(binary()) => %{ update: boolean(), delete: boolean(), merge: boolean() } }
Bulk permission check for multiple sandboxes to avoid N+1 queries.
Returns a map: sandbox_id => %{update: boolean, delete: boolean, merge: boolean}
Assumes root_project.project_users and each sandbox.project_users
are preloaded (as ensured by Projects.list_workspace_projects/2).