mirror of https://github.com/buster-so/buster.git
make sure we have title on chat objects being update
This commit is contained in:
dal
parent
2a61306c17
commit
460a7d0131
|
|
@ -21,7 +21,7 @@ use database::{
|
|||
pool::get_pg_pool,
|
||||
schema::{asset_permissions, chats, messages, messages_to_files},
|
||||
};
|
||||
use diesel::insert_into;
|
||||
use diesel::{insert_into, ExpressionMethods};
|
||||
use diesel_async::RunQueryDsl;
|
||||
use litellm::{
|
||||
AgentMessage as LiteLLMAgentMessage, ChatCompletionRequest, LiteLLMClient, MessageProgress,
|
||||
|
|
@ -436,7 +436,18 @@ pub async fn post_chat_handler(
|
|||
}
|
||||
|
||||
if let Some(title) = title.title {
|
||||
chat_with_messages.title = title;
|
||||
chat_with_messages.title = title.clone();
|
||||
|
||||
// Update the chat title in the database to match
|
||||
let update_result = diesel::update(chats::table)
|
||||
.filter(chats::id.eq(chat_id))
|
||||
.set((chats::title.eq(title), chats::updated_at.eq(Utc::now())))
|
||||
.execute(&mut conn)
|
||||
.await?;
|
||||
|
||||
if update_result == 0 {
|
||||
tracing::warn!("Failed to update chat title in database");
|
||||
}
|
||||
}
|
||||
|
||||
// Send final completed state
|
||||
|
|
@ -1039,7 +1050,7 @@ fn transform_tool_message(
|
|||
"create_dashboards" => tool_create_dashboards(id.clone(), content)?,
|
||||
"update_dashboards" => tool_modify_dashboards(id.clone(), content)?,
|
||||
"create_plan" => tool_create_plan(id.clone(), content)?,
|
||||
_ => return Err(anyhow::anyhow!("Unknown tool name: {}", name)),
|
||||
_ => vec![],
|
||||
};
|
||||
|
||||
Ok(messages)
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
# Chat Permission Checks
|
||||
|
||||
## Problem Statement ✅
|
||||
|
||||
## Problem Statement
|
||||
The chat-related handlers in `@libs/handlers/src/chats` currently lack standardized permission checks using the `@libs/sharing` library. While some permission logic may exist, it doesn't consistently use the `check_asset_permission.rs` functions and doesn't properly handle organization admin access to chat resources.
|
||||
|
||||
Specific issues include:
|
||||
|
|
@ -26,7 +25,7 @@ These issues affect the security and consistency of the application and need to
|
|||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements ✅
|
||||
### Functional Requirements
|
||||
|
||||
#### Core Functionality
|
||||
- Implement permission checks in all chat handlers
|
||||
|
|
@ -66,7 +65,12 @@ These issues affect the security and consistency of the application and need to
|
|||
- Acceptance Criteria: Only chats the user has at least CanView permission for are returned
|
||||
- Dependencies: None
|
||||
|
||||
### Non-Functional Requirements ✅
|
||||
- sharing_endpoint_handlers
|
||||
- Details: Require FullAccess or Owner permission
|
||||
- Acceptance Criteria: Only users with FullAccess or Owner permission can modify sharing settings
|
||||
- Dependencies: None
|
||||
|
||||
### Non-Functional Requirements
|
||||
|
||||
- Performance Requirements
|
||||
- Permission checks should add minimal overhead to handlers (<10ms)
|
||||
|
|
@ -77,7 +81,7 @@ These issues affect the security and consistency of the application and need to
|
|||
- All handlers should use consistent permission checking patterns
|
||||
- Code should be well-documented for future maintenance
|
||||
|
||||
## Technical Design ✅
|
||||
## Technical Design
|
||||
|
||||
### System Architecture
|
||||
|
||||
|
|
@ -91,7 +95,7 @@ graph TD
|
|||
D --> G[Return Error Response]
|
||||
```
|
||||
|
||||
### Core Components ✅
|
||||
### Core Components
|
||||
|
||||
#### Component 1: Permission Check Utility for Chat Handlers
|
||||
|
||||
|
|
@ -221,7 +225,7 @@ pub async fn list_chats_handler(user_id: &Uuid) -> Result<Vec<ChatWithMessages>>
|
|||
}
|
||||
```
|
||||
|
||||
### File Changes ✅
|
||||
### File Changes
|
||||
|
||||
#### Modified Files
|
||||
- `api/libs/handlers/src/chats/get_chat_handler.rs`
|
||||
|
|
@ -251,7 +255,7 @@ pub async fn list_chats_handler(user_id: &Uuid) -> Result<Vec<ChatWithMessages>>
|
|||
|
||||
## Implementation Plan
|
||||
|
||||
### Phase 1: Add Permission Utilities ⏳ (In Progress)
|
||||
### Phase 1: Add Permission Utilities (In Progress)
|
||||
|
||||
1. Create chat-specific permission utility functions
|
||||
- [ ] Implement `verify_chat_permission` helper function
|
||||
|
|
@ -263,7 +267,7 @@ pub async fn list_chats_handler(user_id: &Uuid) -> Result<Vec<ChatWithMessages>>
|
|||
- [ ] Test admin override functionality
|
||||
- [ ] Test error handling and edge cases
|
||||
|
||||
### Phase 2: Modify Chat Handlers 🔜 (Not Started)
|
||||
### Phase 2: Modify Chat Handlers (Not Started)
|
||||
|
||||
1. Update get_chat_handler
|
||||
- [ ] Add permission check for CanView
|
||||
|
|
@ -285,7 +289,7 @@ pub async fn list_chats_handler(user_id: &Uuid) -> Result<Vec<ChatWithMessages>>
|
|||
- [ ] Add logic to include admin-accessible chats
|
||||
- [ ] Update unit tests
|
||||
|
||||
### Phase 3: Testing & Documentation 🔜 (Not Started)
|
||||
### Phase 3: Testing & Documentation (Not Started)
|
||||
|
||||
1. Add integration tests
|
||||
- [ ] Test end-to-end flows with different permission levels
|
||||
|
|
@ -297,7 +301,7 @@ pub async fn list_chats_handler(user_id: &Uuid) -> Result<Vec<ChatWithMessages>>
|
|||
- [ ] Add examples of correct usage
|
||||
- [ ] Document error handling behavior
|
||||
|
||||
## Testing Strategy ✅
|
||||
## Testing Strategy
|
||||
|
||||
### Unit Tests
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Collection Permission Checks
|
||||
|
||||
## Problem Statement ✅
|
||||
## Problem Statement
|
||||
|
||||
The collection-related handlers in `@libs/handlers/src/collections` currently lack standardized permission checks using the `@libs/sharing` library. While some permission logic may exist, it doesn't consistently use the `check_asset_permission.rs` functions and doesn't properly handle organization admin access to collection resources.
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ These issues affect the security and consistency of the application and need to
|
|||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements ✅
|
||||
### Functional Requirements
|
||||
|
||||
#### Core Functionality
|
||||
- Implement permission checks in all collection handlers
|
||||
|
|
@ -76,7 +76,12 @@ These issues affect the security and consistency of the application and need to
|
|||
- Acceptance Criteria: Only users with at least CanEdit permission can remove assets from collections
|
||||
- Dependencies: None
|
||||
|
||||
### Non-Functional Requirements ✅
|
||||
- sharing_endpoint_handlers
|
||||
- Details: Require FullAccess or Owner permission
|
||||
- Acceptance Criteria: Only users with FullAccess or Owner permission can modify sharing settings
|
||||
- Dependencies: None
|
||||
|
||||
### Non-Functional Requirements
|
||||
|
||||
- Performance Requirements
|
||||
- Permission checks should add minimal overhead to handlers (<10ms)
|
||||
|
|
@ -87,7 +92,7 @@ These issues affect the security and consistency of the application and need to
|
|||
- All handlers should use consistent permission checking patterns
|
||||
- Code should be well-documented for future maintenance
|
||||
|
||||
## Technical Design ✅
|
||||
## Technical Design
|
||||
|
||||
### System Architecture
|
||||
|
||||
|
|
@ -101,7 +106,7 @@ graph TD
|
|||
D --> G[Return Error Response]
|
||||
```
|
||||
|
||||
### Core Components ✅
|
||||
### Core Components
|
||||
|
||||
#### Component 1: Permission Check Utility for Collection Handlers
|
||||
|
||||
|
|
@ -341,7 +346,7 @@ pub async fn add_assets_to_collection_handler(
|
|||
}
|
||||
```
|
||||
|
||||
### File Changes ✅
|
||||
### File Changes
|
||||
|
||||
#### Modified Files
|
||||
- `api/libs/handlers/src/collections/get_collection_handler.rs`
|
||||
|
|
@ -381,7 +386,7 @@ pub async fn add_assets_to_collection_handler(
|
|||
|
||||
## Implementation Plan
|
||||
|
||||
### Phase 1: Add Permission Utilities ⏳ (In Progress)
|
||||
### Phase 1: Add Permission Utilities (In Progress)
|
||||
|
||||
1. Create collection-specific permission utility functions
|
||||
- [ ] Implement `verify_collection_permission` helper function
|
||||
|
|
@ -394,7 +399,7 @@ pub async fn add_assets_to_collection_handler(
|
|||
- [ ] Test admin override functionality
|
||||
- [ ] Test error handling and edge cases
|
||||
|
||||
### Phase 2: Modify Collection Handlers 🔜 (Not Started)
|
||||
### Phase 2: Modify Collection Handlers (Not Started)
|
||||
|
||||
1. Update get_collection_handler
|
||||
- [ ] Add permission check for CanView
|
||||
|
|
@ -422,7 +427,7 @@ pub async fn add_assets_to_collection_handler(
|
|||
- [ ] Add permission checks to remove_assets_from_collection_handler
|
||||
- [ ] Update unit tests
|
||||
|
||||
### Phase 3: Testing & Documentation 🔜 (Not Started)
|
||||
### Phase 3: Testing & Documentation (Not Started)
|
||||
|
||||
1. Add integration tests
|
||||
- [ ] Test end-to-end flows with different permission levels
|
||||
|
|
@ -434,7 +439,7 @@ pub async fn add_assets_to_collection_handler(
|
|||
- [ ] Add examples of correct usage
|
||||
- [ ] Document error handling behavior
|
||||
|
||||
## Testing Strategy ✅
|
||||
## Testing Strategy
|
||||
|
||||
### Unit Tests
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
# Dashboard Permission Checks
|
||||
|
||||
## Problem Statement ✅
|
||||
|
||||
## Problem Statement
|
||||
The dashboard-related handlers in `@libs/handlers/src/dashboards` currently lack standardized permission checks using the `@libs/sharing` library. While some permission logic may exist, it doesn't consistently use the `check_asset_permission.rs` functions and doesn't properly handle organization admin access to dashboard resources.
|
||||
|
||||
Specific issues include:
|
||||
|
|
@ -28,7 +27,7 @@ These issues affect the security and consistency of the application and need to
|
|||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements ✅
|
||||
### Functional Requirements
|
||||
|
||||
#### Core Functionality
|
||||
- Implement permission checks in all dashboard handlers
|
||||
|
|
@ -73,8 +72,17 @@ These issues affect the security and consistency of the application and need to
|
|||
- Acceptance Criteria: Only dashboards the user has at least CanView permission for are returned
|
||||
- Dependencies: None
|
||||
|
||||
### Non-Functional Requirements ✅
|
||||
- add_asset_to_dashboard_handler
|
||||
- Details: Require at least CanEdit permission on the dashboard
|
||||
- Acceptance Criteria: Only users with at least CanEdit permission can add assets to dashboards
|
||||
- Dependencies: None
|
||||
|
||||
- sharing_endpoint_handlers
|
||||
- Details: Require FullAccess or Owner permission
|
||||
- Acceptance Criteria: Only users with FullAccess or Owner permission can modify sharing settings
|
||||
- Dependencies: None
|
||||
|
||||
### Non-Functional Requirements
|
||||
- Performance Requirements
|
||||
- Permission checks should add minimal overhead to handlers (<10ms)
|
||||
- Security Requirements
|
||||
|
|
@ -84,7 +92,7 @@ These issues affect the security and consistency of the application and need to
|
|||
- All handlers should use consistent permission checking patterns
|
||||
- Code should be well-documented for future maintenance
|
||||
|
||||
## Technical Design ✅
|
||||
## Technical Design
|
||||
|
||||
### System Architecture
|
||||
|
||||
|
|
@ -98,7 +106,7 @@ graph TD
|
|||
D --> G[Return Error Response]
|
||||
```
|
||||
|
||||
### Core Components ✅
|
||||
### Core Components
|
||||
|
||||
#### Component 1: Permission Check Utility for Dashboard Handlers
|
||||
|
||||
|
|
@ -373,7 +381,7 @@ pub async fn list_dashboard_handler(user_id: &Uuid) -> Result<Vec<DashboardSumma
|
|||
}
|
||||
```
|
||||
|
||||
### File Changes ✅
|
||||
### File Changes
|
||||
|
||||
#### Modified Files
|
||||
- `api/libs/handlers/src/dashboards/get_dashboard_handler.rs`
|
||||
|
|
@ -403,7 +411,7 @@ pub async fn list_dashboard_handler(user_id: &Uuid) -> Result<Vec<DashboardSumma
|
|||
|
||||
## Implementation Plan
|
||||
|
||||
### Phase 1: Add Permission Utilities ⏳ (In Progress)
|
||||
### Phase 1: Add Permission Utilities (In Progress)
|
||||
|
||||
1. Create dashboard-specific permission utility functions
|
||||
- [ ] Implement `verify_dashboard_permission` helper function
|
||||
|
|
@ -417,7 +425,7 @@ pub async fn list_dashboard_handler(user_id: &Uuid) -> Result<Vec<DashboardSumma
|
|||
- [ ] Test CanFilter permission level
|
||||
- [ ] Test error handling and edge cases
|
||||
|
||||
### Phase 2: Modify Dashboard Handlers 🔜 (Not Started)
|
||||
### Phase 2: Modify Dashboard Handlers (Not Started)
|
||||
|
||||
1. Update get_dashboard_handler
|
||||
- [ ] Add permission check for CanView
|
||||
|
|
@ -443,7 +451,7 @@ pub async fn list_dashboard_handler(user_id: &Uuid) -> Result<Vec<DashboardSumma
|
|||
- [ ] Include accurate permission levels in responses
|
||||
- [ ] Update unit tests
|
||||
|
||||
### Phase 3: Testing & Documentation 🔜 (Not Started)
|
||||
### Phase 3: Testing & Documentation (Not Started)
|
||||
|
||||
1. Add integration tests
|
||||
- [ ] Test end-to-end flows with different permission levels
|
||||
|
|
@ -457,7 +465,7 @@ pub async fn list_dashboard_handler(user_id: &Uuid) -> Result<Vec<DashboardSumma
|
|||
- [ ] Document error handling behavior
|
||||
- [ ] Explain CanFilter permission level
|
||||
|
||||
## Testing Strategy ✅
|
||||
## Testing Strategy
|
||||
|
||||
### Unit Tests
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Metric Permission Checks
|
||||
|
||||
## Problem Statement ✅
|
||||
## Problem Statement
|
||||
|
||||
The metric-related handlers in `@libs/handlers/src/metrics` currently lack standardized permission checks using the `@libs/sharing` library. While some permission logic may exist, it doesn't consistently use the `check_asset_permission.rs` functions and doesn't properly handle organization admin access to metric resources.
|
||||
|
||||
|
|
@ -27,7 +27,7 @@ These issues affect the security and consistency of the application and need to
|
|||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements ✅
|
||||
### Functional Requirements
|
||||
|
||||
#### Core Functionality
|
||||
- Implement permission checks in all metric handlers
|
||||
|
|
@ -72,7 +72,12 @@ These issues affect the security and consistency of the application and need to
|
|||
- Acceptance Criteria: Users with at least CanView permission can access metric data
|
||||
- Dependencies: None
|
||||
|
||||
### Non-Functional Requirements ✅
|
||||
- sharing_endpoint_handlers
|
||||
- Details: Require FullAccess or Owner permission
|
||||
- Acceptance Criteria: Only users with FullAccess or Owner permission can modify sharing settings
|
||||
- Dependencies: None
|
||||
|
||||
### Non-Functional Requirements
|
||||
|
||||
- Performance Requirements
|
||||
- Permission checks should add minimal overhead to handlers (<10ms)
|
||||
|
|
@ -83,7 +88,7 @@ These issues affect the security and consistency of the application and need to
|
|||
- All handlers should use consistent permission checking patterns
|
||||
- Code should be well-documented for future maintenance
|
||||
|
||||
## Technical Design ✅
|
||||
## Technical Design
|
||||
|
||||
### System Architecture
|
||||
|
||||
|
|
@ -97,7 +102,7 @@ graph TD
|
|||
D --> G[Return Error Response]
|
||||
```
|
||||
|
||||
### Core Components ✅
|
||||
### Core Components
|
||||
|
||||
#### Component 1: Permission Check Utility for Metric Handlers
|
||||
|
||||
|
|
@ -379,7 +384,7 @@ pub async fn get_metric_data_handler(
|
|||
}
|
||||
```
|
||||
|
||||
### File Changes ✅
|
||||
### File Changes
|
||||
|
||||
#### Modified Files
|
||||
- `api/libs/handlers/src/metrics/get_metric_handler.rs`
|
||||
|
|
@ -409,7 +414,7 @@ pub async fn get_metric_data_handler(
|
|||
|
||||
## Implementation Plan
|
||||
|
||||
### Phase 1: Add Permission Utilities ⏳ (In Progress)
|
||||
### Phase 1: Add Permission Utilities (In Progress)
|
||||
|
||||
1. Create metric-specific permission utility functions
|
||||
- [ ] Implement `verify_metric_permission` helper function
|
||||
|
|
@ -422,7 +427,7 @@ pub async fn get_metric_data_handler(
|
|||
- [ ] Test admin override functionality
|
||||
- [ ] Test error handling and edge cases
|
||||
|
||||
### Phase 2: Modify Metric Handlers 🔜 (Not Started)
|
||||
### Phase 2: Modify Metric Handlers (Not Started)
|
||||
|
||||
1. Update get_metric_handler
|
||||
- [ ] Add permission check for CanView
|
||||
|
|
@ -452,7 +457,7 @@ pub async fn get_metric_data_handler(
|
|||
- [ ] Ensure proper error handling
|
||||
- [ ] Update unit tests
|
||||
|
||||
### Phase 3: Testing & Documentation 🔜 (Not Started)
|
||||
### Phase 3: Testing & Documentation (Not Started)
|
||||
|
||||
1. Add integration tests
|
||||
- [ ] Test end-to-end flows with different permission levels
|
||||
|
|
@ -464,7 +469,7 @@ pub async fn get_metric_data_handler(
|
|||
- [ ] Add examples of correct usage
|
||||
- [ ] Document error handling behavior
|
||||
|
||||
## Testing Strategy ✅
|
||||
## Testing Strategy
|
||||
|
||||
### Unit Tests
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,197 @@
|
|||
---
|
||||
title: API Sharing Permission Requirements
|
||||
author:
|
||||
date: 2025-03-21
|
||||
status: Draft
|
||||
---
|
||||
|
||||
# API Sharing Permission Requirements
|
||||
|
||||
## Problem Statement
|
||||
|
||||
The current permission checks in our API endpoints do not clearly define two critical requirements:
|
||||
|
||||
1. **Adding Assets to Collections/Dashboards**: Permission requirements for adding assets to collections or dashboards are not clearly specified in the existing PRDs.
|
||||
|
||||
2. **Sharing Endpoint Permissions**: The permission level required to access and modify sharing settings via `/sharing` endpoints is not explicitly documented.
|
||||
|
||||
These gaps could lead to inconsistent implementation of permission checks across the application, potentially allowing users with insufficient permissions to perform operations they shouldn't be able to do.
|
||||
|
||||
### Current Limitations
|
||||
|
||||
- Lack of explicit documentation for permission requirements when adding assets to collections/dashboards
|
||||
- No clear standard for permission requirements when accessing `/sharing` endpoints
|
||||
- Potential for inconsistent implementation across different asset types
|
||||
|
||||
### Impact
|
||||
|
||||
- User Impact: Users might unexpectedly be able to or unable to perform certain operations
|
||||
- System Impact: Security vulnerabilities and inconsistent behavior
|
||||
- Business Impact: Potential unauthorized modifications to important business assets
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
#### 1. Adding Assets to Collections/Dashboards
|
||||
|
||||
- Permission Requirement: Users must have at least "CanEdit" permission on a collection or dashboard to add assets to it
|
||||
- Details: This includes CanEdit, FullAccess, or Owner permission levels
|
||||
- Acceptance Criteria: Users with less than CanEdit permission (e.g., CanView, CanFilter) cannot add assets
|
||||
- Dependencies: Existing permission check implementations
|
||||
|
||||
#### 2. Sharing Endpoint Access
|
||||
|
||||
- Permission Requirement: Users must have "FullAccess" or "Owner" permission to access and modify sharing settings
|
||||
- Details: This applies to all `/sharing` endpoints across all asset types
|
||||
- Acceptance Criteria: Users with less than FullAccess permission (e.g., CanView, CanFilter, CanEdit) cannot modify sharing settings
|
||||
- Dependencies: Existing permission check implementations
|
||||
|
||||
### Non-Functional Requirements
|
||||
|
||||
- Consistency: These permission requirements must be applied consistently across all asset types
|
||||
- Documentation: These requirements must be clearly documented in each asset-specific PRD
|
||||
- Testing: Comprehensive tests must verify these permission requirements for all asset types
|
||||
|
||||
## Technical Design
|
||||
|
||||
### Updates to Existing Permission Check Implementations
|
||||
|
||||
For each asset type (Chats, Collections, Dashboards, Metrics), the following updates are required:
|
||||
|
||||
1. **Add Asset to Collection/Dashboard Handler**:
|
||||
|
||||
```rust
|
||||
pub async fn add_asset_to_collection_handler(
|
||||
collection_id: &Uuid,
|
||||
asset_id: &Uuid,
|
||||
asset_type: AssetType,
|
||||
user_id: &Uuid,
|
||||
) -> Result<()> {
|
||||
// Verify user has at least CanEdit permission on the collection
|
||||
verify_collection_permission(collection_id, user_id, AssetPermissionRole::CanEdit).await?;
|
||||
|
||||
// Existing handler logic continues below...
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
2. **Sharing Endpoint Handlers**:
|
||||
|
||||
```rust
|
||||
pub async fn update_sharing_permissions_handler(
|
||||
asset_id: &Uuid,
|
||||
asset_type: AssetType,
|
||||
permissions: Vec<AssetPermission>,
|
||||
user_id: &Uuid,
|
||||
) -> Result<()> {
|
||||
// Verify user has at least FullAccess permission
|
||||
match asset_type {
|
||||
AssetType::Chat => {
|
||||
verify_chat_permission(asset_id, user_id, AssetPermissionRole::FullAccess).await?;
|
||||
},
|
||||
AssetType::Collection => {
|
||||
verify_collection_permission(asset_id, user_id, AssetPermissionRole::FullAccess).await?;
|
||||
},
|
||||
AssetType::DashboardFile => {
|
||||
verify_dashboard_permission(asset_id, user_id, AssetPermissionRole::FullAccess).await?;
|
||||
},
|
||||
AssetType::Metric => {
|
||||
verify_metric_permission(asset_id, user_id, AssetPermissionRole::FullAccess).await?;
|
||||
},
|
||||
_ => return Err(anyhow!("Unsupported asset type for sharing")),
|
||||
}
|
||||
|
||||
// Existing handler logic continues below...
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
### Updates to Existing PRDs
|
||||
|
||||
Each of the following PRDs needs to be updated to include these permission requirements:
|
||||
- `api_chat_permission_checks.md`
|
||||
- `api_collection_permission_checks.md`
|
||||
- `api_dashboard_permission_checks.md`
|
||||
- `api_metric_permission_checks.md`
|
||||
|
||||
## Implementation Plan
|
||||
|
||||
### Tasks
|
||||
1. Update all asset-specific PRDs to include these requirements
|
||||
2. Ensure all existing and new handlers implement these permission checks
|
||||
3. Add tests to verify these permission requirements
|
||||
|
||||
### Dependencies
|
||||
- Existing permission check functions in each asset handler
|
||||
- Existing sharing library components
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
### Unit Tests
|
||||
|
||||
For each asset type, add the following test cases:
|
||||
|
||||
#### Collection/Dashboard Asset Addition Permission Tests
|
||||
|
||||
```rust
|
||||
#[tokio::test]
|
||||
async fn test_add_asset_to_collection_with_canview_fails() {
|
||||
// Arrange: Set up user with only CanView permission on collection
|
||||
// Act: Attempt to add asset to collection
|
||||
// Assert: Operation fails with permission error
|
||||
}
|
||||
|
||||
#[tokio::test]
|
||||
async fn test_add_asset_to_collection_with_canedit_succeeds() {
|
||||
// Arrange: Set up user with CanEdit permission on collection
|
||||
// Act: Attempt to add asset to collection
|
||||
// Assert: Operation succeeds
|
||||
}
|
||||
|
||||
#[tokio::test]
|
||||
async fn test_add_asset_to_collection_with_fullaccess_succeeds() {
|
||||
// Arrange: Set up user with FullAccess permission on collection
|
||||
// Act: Attempt to add asset to collection
|
||||
// Assert: Operation succeeds
|
||||
}
|
||||
```
|
||||
|
||||
#### Sharing Endpoint Permission Tests
|
||||
|
||||
```rust
|
||||
#[tokio::test]
|
||||
async fn test_update_sharing_with_canedit_fails() {
|
||||
// Arrange: Set up user with only CanEdit permission on asset
|
||||
// Act: Attempt to update sharing settings
|
||||
// Assert: Operation fails with permission error
|
||||
}
|
||||
|
||||
#[tokio::test]
|
||||
async fn test_update_sharing_with_fullaccess_succeeds() {
|
||||
// Arrange: Set up user with FullAccess permission on asset
|
||||
// Act: Attempt to update sharing settings
|
||||
// Assert: Operation succeeds
|
||||
}
|
||||
|
||||
#[tokio::test]
|
||||
async fn test_update_sharing_with_owner_succeeds() {
|
||||
// Arrange: Set up user with Owner permission on asset
|
||||
// Act: Attempt to update sharing settings
|
||||
// Assert: Operation succeeds
|
||||
}
|
||||
```
|
||||
|
||||
### Integration Tests
|
||||
|
||||
For each asset type, integration tests should verify:
|
||||
1. A user with only CanView cannot add assets to collections/dashboards or modify sharing settings
|
||||
2. A user with CanEdit can add assets but cannot modify sharing settings
|
||||
3. A user with FullAccess can both add assets and modify sharing settings
|
||||
4. A user with Owner permission can both add assets and modify sharing settings
|
||||
|
||||
## Security Considerations
|
||||
|
||||
- Permission checks must happen at the beginning of handlers before any operations
|
||||
- Failed permission checks should return consistent error messages that don't reveal sensitive information
|
||||
- These permission requirements should be consistently enforced across all API endpoints, including REST and WebSocket interfaces
|
||||
|
|
@ -27,6 +27,8 @@ This project aims to standardize asset permission checks across all asset endpoi
|
|||
3. Ensure proper permission levels are enforced based on asset type (CanView, CanFilter, CanEdit, FullAccess, Owner)
|
||||
4. Standardize error handling for permission-denied scenarios
|
||||
5. Ensure comprehensive test coverage for permission checks
|
||||
6. Enforce consistent permission requirements for adding assets to collections/dashboards
|
||||
7. Enforce consistent permission requirements for accessing and modifying sharing settings
|
||||
|
||||
## Non-Goals
|
||||
|
||||
|
|
@ -100,6 +102,13 @@ graph TD
|
|||
- Input: Metric handlers
|
||||
- Output: Modified handlers with permission checks
|
||||
|
||||
#### Component 6: Sharing Permission Requirements
|
||||
- Purpose: Define consistent permission requirements for sharing endpoints and adding assets to collections/dashboards
|
||||
- Sub-PRD: [Sharing Permission Requirements](api_sharing_permission_requirements.md)
|
||||
- Interfaces:
|
||||
- Input: Asset handlers related to sharing and asset additions
|
||||
- Output: Modified handlers with consistent permission checks
|
||||
|
||||
### Dependencies
|
||||
|
||||
1. `@libs/sharing/src/check_asset_permission.rs` - Used for asset permission checks
|
||||
|
|
@ -141,6 +150,11 @@ The following can be developed concurrently after the admin check is implemented
|
|||
- Required for: None
|
||||
- No conflicts with other asset types
|
||||
|
||||
6. [Sharing Permission Requirements](api_sharing_permission_requirements.md) - **Can be developed concurrently**
|
||||
- Dependencies: Asset Permission Admin Check
|
||||
- Required for: None
|
||||
- No conflicts with other asset types
|
||||
|
||||
### Concurrent Development Strategy
|
||||
|
||||
To enable efficient concurrent development without conflicts:
|
||||
|
|
@ -168,6 +182,7 @@ To enable efficient concurrent development without conflicts:
|
|||
- Collection Permission Checks
|
||||
- Dashboard Permission Checks
|
||||
- Metric Permission Checks
|
||||
- Sharing Permission Requirements
|
||||
|
||||
**Success Criteria:**
|
||||
- All handlers implement permission checks
|
||||
|
|
@ -223,3 +238,4 @@ To enable efficient concurrent development without conflicts:
|
|||
- [Collection Permission Checks](api_collection_permission_checks.md)
|
||||
- [Dashboard Permission Checks](api_dashboard_permission_checks.md)
|
||||
- [Metric Permission Checks](api_metric_permission_checks.md)
|
||||
- [Sharing Permission Requirements](api_sharing_permission_requirements.md)
|
||||
Loading…
Reference in New Issue