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:

// 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:

// 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.