buster/api/prds/active/sharing_access_controls_summary.md

Sharing Access Controls Summary PRD

Overview

This document provides a high-level summary of the sharing access controls implementation, divided into modular, testable tickets. Each component has its own detailed PRD for implementation.

Components

1. User Lookup by Email

PRD: sharing_user_lookup.md

Implements functionality to look up users by their email addresses, which is essential for email-based sharing features.

Key Function:

pub async fn find_user_by_email(email: &str) -> Result<Option<User>>;

2. Create/Update Asset Permissions

PRD: sharing_create_permissions.md

Implements functionality to create or update permissions for a user on an asset, using email address as the identifier.

Key Function:

pub async fn create_share_by_email(
    email: &str,
    asset_id: Uuid,
    asset_type: AssetType,
    role: AssetPermissionRole,
    created_by: Uuid,
) -> Result<AssetPermission>;

Permission Required: Owner or FullAccess

3. Remove Asset Permissions

PRD: sharing_remove_permissions.md

Implements functionality to remove a user's permissions for an asset, using email address as the identifier.

Key Function:

pub async fn remove_share_by_email(
    email: &str,
    asset_id: Uuid,
    asset_type: AssetType,
    updated_by: Uuid,
) -> Result<()>;

Permission Required: Owner or FullAccess

4. List Asset Permissions

PRD: sharing_list_permissions.md

Implements functionality to list all permissions for a given asset.

Key Function:

pub async fn list_shares(
    asset_id: Uuid,
    asset_type: AssetType,
) -> Result<Vec<AssetPermissionWithUser>>;

Permission Required: All permission levels

5. Check Asset Permissions

PRD: sharing_check_permissions.md

Implements functionality to check if a user has the required permission level for an asset.

Key Functions:

pub async fn check_access(
    asset_id: Uuid,
    asset_type: AssetType,
    identity_id: Uuid,
    identity_type: IdentityType,
) -> Result<Option<AssetPermissionRole>>;

pub async fn has_permission(
    asset_id: Uuid,
    asset_type: AssetType,
    identity_id: Uuid,
    identity_type: IdentityType,
    required_role: AssetPermissionRole,
) -> Result<bool>;

Permission Required: Internal function, no permission requirements

Implementation Strategy

These components should be implemented in the following order:

1. User Lookup by Email
2. Check Asset Permissions
3. Create/Update Asset Permissions
4. Remove Asset Permissions
5. List Asset Permissions

This order ensures that dependencies are satisfied before they are needed by other components.

Testing Strategy

Each component should have:

1. Unit Tests: Test individual functions with mocked dependencies
2. Integration Tests: Test the interaction between components
3. Permission Tests: Verify permission checks are enforced correctly
4. Error Handling Tests: Verify proper error handling for edge cases

Success Metrics

• All functions pass unit and integration tests
• Performance meets requirements (response times under 100ms)
• Error handling is robust and user-friendly
• Code is modular and maintainable