Roles & Permissions
Understand how roles and permissions work in SeeMe.ai.
How Roles Work
Roles are collections of permissions assigned at different scopes:
graph LR
R[Role] --> P1[Permission 1]
R --> P2[Permission 2]
R --> P3[Permission 3]
U[User] --> RM[Role Membership]
RM --> R
RM --> S[Scope: Org/Team/Project]Permission Format
Permissions follow the pattern: resource:action
models:read → Can view models
models:write → Can modify models
datasets:delete → Can delete datasets
workflows:* → All workflow permissions (wildcard)System Roles
These are built-in roles that cannot be modified.
Organization Roles
Team Roles
Project Roles
Share Roles
Used when sharing individual resources.
| Role | Permissions |
|---|---|
| share_viewer | Read access only |
| share_editor | Read + write access |
Custom Roles
Create custom roles for specific needs.
Create Custom Role
## Create a role for ML engineers
role = client.create_role(
organization_id=org.id,
name="ML Engineer",
slug="ml_engineer",
scope="project",
permissions=[
"models:read",
"models:write",
"models:predict",
"datasets:read",
"datasets:write",
"datasets:annotate",
"jobs:read",
"jobs:write"
]
)Update Role Permissions
# Add inference permission to role
client.update_role(
role_id=role.id,
permissions=[
*role.permissions,
"models:download" # Add new permission
]
)Delete Custom Role
# Only custom roles can be deleted
client.delete_role(role_id=role.id)Assigning Roles
Assign to Organization Member
# Invite user with specific role
client.invite_organization_member(
organization_id=org.id,
email="user@example.com",
role="org_admin"
)
# Change existing member's role
client.update_organization_member(
organization_id=org.id,
user_id=user.id,
role="org_member"
)Assign to Team Member
# Add user to team with role
client.add_team_member(
team_id=team.id,
user_id=user.id,
role="team_lead"
)Assign to Project Member
# Add user to project with role
client.add_project_member(
project_id=project.id,
user_id=user.id,
role="project_editor"
)Permission Checking
How Access is Evaluated
graph TD
A[Access Request] --> B{System Admin?}
B -->|Yes| C[Allow]
B -->|No| D{Resource Owner?}
D -->|Yes| C
D -->|No| E{Check Visibility}
E --> F{Public?}
F -->|Yes| C
F -->|No| G{Org Visibility?}
G -->|Yes| H{User in Org?}
H -->|Yes| I{Has Permission?}
I -->|Yes| C
I -->|No| J[Deny]
H -->|No| J
G -->|No| K{Team Visibility?}
K -->|Yes| L{User in Team?}
L -->|Yes| I
L -->|No| J
K -->|No| M{Explicit Grant?}
M -->|Yes| I
M -->|No| JCheck Permissions in Code
# Check if current user can access a model
can_access = client.check_permission(
resource_type="model",
resource_id=model.id,
action="predict"
)
if can_access:
result = client.predict(model_id=model.id, ...)
else:
print("Access denied")Permission Reference
Full Permission List
| Resource | Permissions |
|---|---|
| models | read, write, delete, predict, download |
| datasets | read, write, delete, annotate, download |
| workflows | read, write, delete, execute |
| graphs | read, write, delete, query |
| jobs | read, write, cancel |
| projects | read, write, delete, manage |
| teams | read, write, manage |
| org | read, write, manage, billing |
Wildcards
Use * for all actions on a resource:
permissions=[
"models:*", # All model permissions
"datasets:read" # Only read datasets
]Best Practices
- Start restrictive - Add permissions as needed
- Use project roles - More granular than org roles
- Custom roles for specific needs - Don’t modify system roles
- Regular audits - Review role assignments quarterly
- Document custom roles - Explain what each role is for