Dataset Access Control#

RAGFlow controls dataset (knowledgebase) visibility at two levels: ownership and team sharing. Every dataset carries a permission field on the Knowledgebase model that takes one of two values defined by the TenantPermission enum:

The permission field defaults to "me" 1. It can be set at creation time or updated via PUT /datasets/<dataset_id> 2. The SDK exposes it as a top-level field on the DataSet object 3.

UserTenant and Team Membership#

Cross-tenant sharing relies on the UserTenant junction table, which records each user's membership in tenants they did not create:

• user_id — the accessing user
• tenant_id — the tenant being joined
• role — one of owner, admin, normal, invite (defined in UserTenantRole)
• status — "1" (valid) or "0" (wasted)

TenantService.get_joined_tenants_by_user_id(user_id) returns all tenants where the user holds a NORMAL role and status = "1". This is the key query behind every team-permission check.

Permission Enforcement#

Core access check: KnowledgebaseService.accessible()#

All read operations and most write operations go through KnowledgebaseService.accessible(kb_id, user_id), which implements this logic:

1. Fetch the knowledgebase record; return False if not found or status != VALID.
2. If kb.tenant_id == user_id → owner access, return True.
3. If kb.permission != "team" → return False.
4. Otherwise, call TenantService.get_joined_tenants_by_user_id(user_id) and return True only if the KB's tenant_id appears in the result.

This same logic is also encapsulated in the standalone helper check_kb_team_permission(kb, other) used by the file-permission layer.

Listing datasets: _visibility_and_status_filter()#

When listing datasets, KnowledgebaseService._visibility_and_status_filter(joined_tenant_ids, user_id) produces a single Peewee WHERE clause:

(tenant_id IN joined_tenant_ids AND permission = 'team')
  OR tenant_id = user_id
AND status = VALID

This is applied by get_list(), get_by_tenant_ids(), get_accessible_ids(), and get_owner_filter().

In the service layer, list_datasets() pre-computes joined_tenant_ids via TenantService.get_joined_tenants_by_user_id() before calling KnowledgebaseService.get_list().

Delete: owner-only#

Delete is stricter than read. _delete_datasets_sync() uses KnowledgebaseService.get_or_none(id=kb_id, tenant_id=tenant_id) — a direct equality check against tenant_id, not the broader accessible() check. Team members can read a shared dataset but cannot delete it 4.

Update: accessible check#

update_dataset() calls KnowledgebaseService.get_kb_by_id(dataset_id, tenant_id), which internally calls accessible(). Team members with permission = "team" can update a dataset they can see 5.

Metadata configuration: owner-only#

get_auto_metadata() and update_auto_metadata() use KnowledgebaseService.get_or_none(id=dataset_id, tenant_id=tenant_id) — a strict owner check, not the team-accessible path 6.

Access Control by Operation#

For bulk list filtering, KnowledgebaseService.get_accessible_ids() is used to silently drop denied IDs rather than returning an error 7.

Key Files and Entry Points#