feat(workspaces): add rwx perms to blueprints and ranges

[Adamkadaban]

Checklist

• I have added a version label to my PR (e.g., patch, minor, major).
• I have tested my changes locally and verified they work as expected.
• I have added relevant tests to cover my changes.
• I have made any necessary updates to the documentation.
• I have made any necessary updates to the CLI.
• I have made any necessary updates to the frontend.

Description

This pull request introduces a permissions system for managing access to blueprint and deployed ranges in the application. Key changes include adding CRUD operations for permissions, updating range-related methods to enforce permissions, and extending the data models to support these changes.

Permissions Management:

• Added CRUD functions for granting and revoking permissions (grant_blueprint_permission, grant_deployed_permission, revoke_blueprint_permission, revoke_deployed_permission) in crud_permissions.py. These functions handle database operations and include logging for success and failure cases.

• Introduced helper functions (can_read_blueprint, can_write_blueprint, can_read_deployed, can_write_deployed, can_execute_deployed) in crud_ranges.py to check user permissions for blueprint and deployed ranges. These functions ensure that access control is enforced consistently.

Updates to Range Operations:

• Updated methods like get_blueprint_range_headers, get_blueprint_range, create_blueprint_range, and delete_blueprint_range in crud_ranges.py to incorporate permission checks and manage permissions during creation and deletion. Similar changes were made for deployed ranges. [1] [2] [3] [4] [5] [6] [7] [8]

• Modified range creation methods to grant permissions to specified readers, writers, and executors during the creation of blueprint and deployed ranges. [1] [2]

Data Model Enhancements:

• Added BlueprintRangePermissionModel and DeployedRangePermissionModel to represent permissions in the database. These models were integrated into the existing data model structure. [1] [2]

• Updated range models to include a permissions relationship for loading associated permissions, enabling efficient permission checks. [1] [2]

Query Adjustments:

• Enhanced database queries for fetching blueprint and deployed ranges to include permission-based filtering, ensuring that users only see ranges they are authorized to access. [1] [2]

These changes collectively improve the application's access control mechanisms, ensuring that permissions are consistently enforced across all operations involving blueprint and deployed ranges.

Fixes: #66

[Copilot]

Pull Request Overview

This pull request introduces a comprehensive permissions system for managing access to blueprint and deployed ranges in the application, enabling fine-grained control over who can read, write, and execute ranges beyond simple ownership.

• Added CRUD operations for granting and revoking permissions for both blueprint and deployed ranges
• Updated range-related methods to enforce permission checks before allowing access or operations
• Extended data models with permission relationships and created new permission models

Reviewed Changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
api/src/app/models/permission_models.py	Created new permission models for blueprint and deployed ranges with proper constraints
api/src/app/crud/crud_permissions.py	Implemented CRUD functions for granting and revoking permissions with error handling
api/src/app/crud/crud_ranges.py	Updated range operations to include permission checks and grant permissions during creation
api/src/app/schemas/range_schemas.py	Added permission fields to create schemas and computed fields to response schemas
api/src/app/models/range_models.py	Added permission relationships to range models
api/tests/unit/crud/test_crud_permissions.py	Added comprehensive tests for permission CRUD operations
api/tests/unit/crud/test_crud_ranges.py	Updated range key access tests to reflect new permission-based logic

Comments suppressed due to low confidence (1)

api/src/app/crud/crud_ranges.py:163

• The db.delete() method is being called but the actual SQLAlchemy delete operation requires db.delete(permission) to be called on the session. The code should use await db.delete(permission) instead of db.delete(permission).

    )

[alexchristy]

Looking good so far! I love to see the tests. For the permission types, do you think you could clarify the meanings of each type of permission?

From the review this is my understanding:

• Readers can read the corresponding database record
• Blueprint writers can deploy and edit the blueprint?
• Deployed range writers can edit the resources of a live range?
• Deployed range executors can interact with a live range