buster/api/prds/active/sharing_check_permissions.md

# Check Asset Permissions PRD ✅

## Overview
This PRD outlines the implementation of functionality to check if a user has the required permission level for an asset within the sharing access controls system.

## Background
The system needs to verify that users have appropriate permissions before allowing them to perform actions on assets. This requires enhancing and enabling the existing permission checking functionality.

## Goals
- ✅ Enable and enhance the existing `check_asset_permission.rs` module
- ✅ Ensure the function checks if a user has the required permission level
- ✅ Support checking against specific permission levels
- ✅ Optimize for performance with caching if necessary

## Non-Goals
- Implementing UI components for permission checking
- Complex permission hierarchies beyond what's already defined
- Implementing new permission types

## Technical Design

### Component: Enhanced Check Asset Permission Module

Uncomment and enhance the existing `check_asset_permission.rs` module in the library:

```rust
// Already exists in the codebase
pub async fn check_access(
    asset_id: Uuid,
    asset_type: AssetType,
    identity_id: Uuid,
    identity_type: IdentityType,
) -> Result<Option<AssetPermissionRole>> {
    // Implementation details
}

// Add a new helper function
pub async fn has_permission(
    asset_id: Uuid,
    asset_type: AssetType,
    identity_id: Uuid,
    identity_type: IdentityType,
    required_role: AssetPermissionRole,
) -> Result<bool> {
    // Implementation details
}
```

### Implementation Details

1. Uncomment the existing `check_asset_permission` module in `lib.rs`
2. Implement the new `has_permission` function that uses `check_access`
3. The function will check if the user's permission level is sufficient for the required role
4. It will use the role hierarchy defined in the `AssetPermissionRole` enum

### Permission Hierarchy

The function will use the existing `max` function in `AssetPermissionRole` to compare permission levels:

```rust
// Example implementation
pub async fn has_permission(
    asset_id: Uuid,
    asset_type: AssetType,
    identity_id: Uuid,
    identity_type: IdentityType,
    required_role: AssetPermissionRole,
) -> Result<bool> {
    let user_role = check_access(asset_id, asset_type, identity_id, identity_type).await?;
    
    match user_role {
        Some(role) => {
            // Check if user's role is sufficient for the required role
            // This logic depends on how roles are compared in your system
            Ok(matches!(
                (role, required_role),
                (AssetPermissionRole::Owner, _) |
                (AssetPermissionRole::FullAccess, _) |
                (AssetPermissionRole::CanEdit, AssetPermissionRole::CanEdit | AssetPermissionRole::CanView) |
                (AssetPermissionRole::CanView, AssetPermissionRole::CanView)
            ))
        }
        None => Ok(false),
    }
}
```

### Error Handling

The function should handle the following error cases:
- Database connection errors
- Query execution errors
- Invalid asset ID or type

## Testing Strategy

### Unit Tests
- Test checking permissions for users with different permission levels
- Test checking against different required permission levels
- Test handling users without permissions
- Test error handling for database issues

### Integration Tests
- Test the function in combination with permission creation and removal

## Dependencies
- Database models and schema
- Diesel ORM
- Error handling utilities

## Implementation Plan
1. ✅ Uncomment the `check_asset_permission` module in `lib.rs`
2. ✅ Implement the `has_permission` function
3. ✅ Add error handling
4. ✅ Write tests
5. ✅ Update the library exports in `lib.rs`

## Success Criteria
- ✅ Function correctly checks if a user has the required permission level
- ✅ Appropriate error handling is implemented
- ✅ Tests pass successfully
- ✅ Code is well-documented

## Permission Requirements
- Internal function, no permission requirements

## Implementation Summary
- ✅ Uncommented the `check_asset_permission` module in `lib.rs`
- ✅ Implemented the `has_permission` function with a robust permission hierarchy
- ✅ Fixed issues with the bulk permission checking approach to be more memory efficient
- ✅ Added comprehensive role checks for all permission levels
- ✅ Created test cases to verify functionality
- ✅ Ensured all functions are properly exported
- ✅ Completed all required implementation tasks

The implementation is now ready for review and integration with the rest of the access controls system.