mirror of https://github.com/buster-so/buster.git
120 lines
3.4 KiB
Markdown
120 lines
3.4 KiB
Markdown
|
# 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](/prds/active/sharing_user_lookup.md)
|
||
|
|
||
|
Implements functionality to look up users by their email addresses, which is essential for email-based sharing features.
|
||
|
|
||
|
**Key Function**:
|
||
|
```rust
|
||
|
pub async fn find_user_by_email(email: &str) -> Result<Option<User>>;
|
||
|
```
|
||
|
|
||
|
### 2. Create/Update Asset Permissions
|
||
|
**PRD**: [sharing_create_permissions.md](/prds/active/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**:
|
||
|
```rust
|
||
|
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](/prds/active/sharing_remove_permissions.md)
|
||
|
|
||
|
Implements functionality to remove a user's permissions for an asset, using email address as the identifier.
|
||
|
|
||
|
**Key Function**:
|
||
|
```rust
|
||
|
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](/prds/active/sharing_list_permissions.md)
|
||
|
|
||
|
Implements functionality to list all permissions for a given asset.
|
||
|
|
||
|
**Key Function**:
|
||
|
```rust
|
||
|
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](/prds/active/sharing_check_permissions.md)
|
||
|
|
||
|
Implements functionality to check if a user has the required permission level for an asset.
|
||
|
|
||
|
**Key Functions**:
|
||
|
```rust
|
||
|
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
|