make sure we have title on chat objects being update

2025-03-21 15:07:50 -06:00 · 2025-03-21 15:07:50 -06:00 · 460a7d0131
parent 2a61306c17
commit 460a7d0131
7 changed files with 292 additions and 46 deletions
--- a/api/libs/handlers/src/chats/post_chat_handler.rs
+++ b/api/libs/handlers/src/chats/post_chat_handler.rs
@ -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)
--- a/api/prds/active/api_chat_permission_checks.md
+++ b/api/prds/active/api_chat_permission_checks.md
@ -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

--- a/api/prds/active/api_collection_permission_checks.md
+++ b/api/prds/active/api_collection_permission_checks.md
@ -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

--- a/api/prds/active/api_dashboard_permission_checks.md
+++ b/api/prds/active/api_dashboard_permission_checks.md
@ -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

--- a/api/prds/active/api_metric_permission_checks.md
+++ b/api/prds/active/api_metric_permission_checks.md
@ -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

--- a/api/prds/active/api_sharing_permission_requirements.md
+++ b/api/prds/active/api_sharing_permission_requirements.md
@ -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
--- a/api/prds/active/project_asset_permission_checks.md
+++ b/api/prds/active/project_asset_permission_checks.md
@ -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
@ -222,4 +237,5 @@ To enable efficient concurrent development without conflicts:
 - [Chat Permission Checks](api_chat_permission_checks.md)
 - [Collection Permission Checks](api_collection_permission_checks.md)
 - [Dashboard Permission Checks](api_dashboard_permission_checks.md)
- [Metric Permission Checks](api_metric_permission_checks.md)
+- [Metric Permission Checks](api_metric_permission_checks.md)
+- [Sharing Permission Requirements](api_sharing_permission_requirements.md)