Principle:OpenHands OpenHands Ownership Establishment
| Knowledge Sources | |
|---|---|
| Domains | Organization_Management, Multi_Tenancy |
| Last Updated | 2026-02-11 21:00 GMT |
Overview
Establishing ownership relationships between users and organizations via RBAC roles ensures the creating user has full administrative authority over the new entity from the moment of creation.
Description
The Ownership Establishment principle implements a role-based access control (RBAC) pattern that links a user to an organization with a specific permission set. During onboarding, the user who creates an organization is automatically assigned the Owner role, granting them the highest level of permissions within that organization. This involves two operations:
- Role resolution: Retrieving or identifying the predefined Owner role from the role catalog.
- Membership creation: Constructing an OrgMember entity that binds the user ID, organization ID, and role together.
This pattern ensures that no organization exists without at least one user who can manage it, preventing "orphaned" organizations that no one can administer.
Usage
Apply this principle whenever a new organizational entity is created and requires an initial administrative user. Common scenarios include:
- Assigning the Owner role to the organization creator during onboarding
- Establishing initial team leads when creating sub-teams within an organization
- Any situation where a newly created resource must have an immediately-active access control binding
Theoretical Basis
The RBAC ownership pattern follows a resolve-role-then-bind sequence:
# Pseudocode for ownership establishment
def establish_ownership(org_id, user_id):
# Step 1: Resolve the owner role from the role catalog
owner_role = role_catalog.get_role(name="Owner")
# Step 2: Create the membership binding
membership = OrgMember(
org_id=org_id,
user_id=user_id,
role_id=owner_role.id,
settings=default_member_settings(),
)
return membership
Key considerations:
- Role immutability: The Owner role definition should be a system-managed constant, not user-editable, to prevent privilege escalation.
- Single source of truth: The role is resolved from a centralized catalog rather than hardcoded as an ID, ensuring consistency if role IDs change between environments.
- Atomic binding: The membership record should be persisted in the same transaction as the organization entity to guarantee that no org exists without an owner.