Feature: Implement Backend API Endpoints for Resource Sharing & Group Management #106

New issue

Closed

opened 2025-10-08 19:02:55 +00:00 by rwachters · 0 comments

rwachters commented

2025-10-08 19:02:55 +00:00

(Migrated from github.com)

Issue Type: Feature / Backend
Priority: High

Description

The core backend infrastructure for resource sharing and access control (authentication, authorization, ownership, group-based access) for providers, models, and settings is complete as per the Phase 3 Backend Readiness Report. However, the API layer required for the frontend to manage these features is currently missing. This issue tracks the implementation of these critical backend API endpoints.

Without these endpoints, the frontend cannot:

Manage user groups (create, update, delete, add/remove members).
Grant or revoke access to resources (providers, models, settings) for specific user groups.
Toggle the public/private status of resources.
Query ownership information for resources.

This issue aims to address the "Critical Backend Gaps" identified in the report, following the recommended implementation priority.

Tasks & Implementation Priorities

The following tasks are prioritized to unblock frontend development:

Priority 1: User Group Management Endpoints ⚠️ CRITICAL

Estimated Duration: 1-2 days

Description: Implement a comprehensive set of API endpoints for managing user groups and their memberships. This is critical as user groups are the foundation for resource sharing.

Missing Routes to Implement:

GET /api/v1/user-groups: List all user groups.
POST /api/v1/user-groups: Create a new user group.
GET /api/v1/user-groups/{id}: Retrieve details for a specific user group.
PUT /api/v1/user-groups/{id}: Update an existing user group's name or description.
DELETE /api/v1/user-groups/{id}: Delete a user group (with protection for special groups like "All Users").
GET /api/v1/user-groups/{id}/members: List all members of a specific user group.
POST /api/v1/user-groups/{id}/members: Add a user to a specific user group.
DELETE /api/v1/user-groups/{id}/members/{userId}: Remove a user from a specific user group.

Implementation Notes:

Create a new file: server/src/main/kotlin/eu/torvian/chatbot/server/routes/configureUserGroupRoutes.kt
Utilize the existing UserGroupService for business logic.
Ensure proper authentication (AuthSchemes.USER_JWT) and authorization (e.g., MANAGE_USER_GROUPS permission for CRUD operations).

Priority 2: Resource Access Management Endpoints ⚠️ HIGH

Estimated Duration: 2-3 days

Description: Implement API endpoints to grant, revoke, and query access for user groups to providers, models, and settings. This is the core functionality for resource sharing.

Missing Routes to Implement:

POST /api/v1/providers/{id}/access: Grant a specific access mode (e.g., READ, WRITE) to a user group for a provider.
DELETE /api/v1/providers/{id}/access: Revoke a specific access mode from a user group for a provider.
GET /api/v1/providers/{id}/access: List all user groups that have any access to a provider, along with their access modes.
(Repeat the above three routes for /api/v1/models/{id}/access)
(Repeat the above three routes for /api/v1/settings/{id}/access)

Implementation Notes:

Add these routes to the existing configureProviderRoutes.kt, configureModelRoutes.kt, and configureSettingsRoutes.kt files.
Introduce new service-level methods (e.g., in LlmProviderService, LlmModelService, ModelSettingsService) to wrap the ProviderAccessDao, ModelAccessDao, and SettingsAccessDao operations.
Ensure proper authorization checks using the respective ResourceAuthorizer implementations.

Priority 3: Convenience Endpoints (Make Public/Private) 📊 MEDIUM

Estimated Duration: 1 day

Description: Implement convenience endpoints to easily toggle the public/private status of resources. These endpoints will internally use the grant/revoke access logic with the "All Users" group.

Missing Routes to Implement:

POST /api/v1/providers/{id}/make-public: Grant READ access to the "All Users" group for a provider.
POST /api/v1/providers/{id}/make-private: Revoke READ access from the "All Users" group for a provider.
GET /api/v1/providers/{id}/is-public: Check if a provider is public (i.e., "All Users" group has READ access).
(Repeat the above three routes for /api/v1/models/{id})
(Repeat the above three routes for /api/v1/settings/{id})

Implementation Notes:

Add these routes to the existing route configuration files.
Introduce new service methods (e.g., makeProviderPublic, makeProviderPrivate, isProviderPublic) that leverage the UserGroupService to get the "All Users" group and then call the resource access management service methods.

Priority 4: Ownership Information Endpoints 📊 MEDIUM

Estimated Duration: 0.5 day

Description: Implement endpoints to retrieve the owner information for a given resource.

Missing Routes to Implement:

GET /api/v1/providers/{id}/owner: Get the user details of the owner of a provider.
GET /api/v1/models/{id}/owner: Get the user details of the owner of a model.
GET /api/v1/settings/{id}/owner: Get the user details of the owner of a settings profile.

Implementation Notes:

Add these routes to the existing route configuration files.
Introduce new service methods (e.g., getProviderOwner, getModelOwner, getSettingsOwner) that use the respective Ownership DAOs to retrieve the owner ID and then fetch user details from the UserService.

Acceptance Criteria

All specified API endpoints are implemented and accessible.
Endpoints adhere to Ktor's authentication (AuthSchemes.USER_JWT) and authorization standards.
Appropriate service-level methods are created to encapsulate business logic.
All new endpoints are covered by unit and/or integration tests.
Error handling is consistent (e.g., using Either for results and call.respondEither).

Labels

backend, api, feature, priority: high, phase3

## Feature: Implement Backend API Endpoints for Resource Sharing & Group Management **Issue Type:** Feature / Backend **Priority:** High ### Description The core backend infrastructure for resource sharing and access control (authentication, authorization, ownership, group-based access) for providers, models, and settings is complete as per the Phase 3 Backend Readiness Report. However, the API layer required for the frontend to manage these features is currently missing. This issue tracks the implementation of these critical backend API endpoints. Without these endpoints, the frontend cannot: * Manage user groups (create, update, delete, add/remove members). * Grant or revoke access to resources (providers, models, settings) for specific user groups. * Toggle the public/private status of resources. * Query ownership information for resources. This issue aims to address the "Critical Backend Gaps" identified in the report, following the recommended implementation priority. --- ### Tasks & Implementation Priorities The following tasks are prioritized to unblock frontend development: #### Priority 1: User Group Management Endpoints ⚠️ CRITICAL **Estimated Duration:** 1-2 days **Description:** Implement a comprehensive set of API endpoints for managing user groups and their memberships. This is critical as user groups are the foundation for resource sharing. **Missing Routes to Implement:** * `GET /api/v1/user-groups`: List all user groups. * `POST /api/v1/user-groups`: Create a new user group. * `GET /api/v1/user-groups/{id}`: Retrieve details for a specific user group. * `PUT /api/v1/user-groups/{id}`: Update an existing user group's name or description. * `DELETE /api/v1/user-groups/{id}`: Delete a user group (with protection for special groups like "All Users"). * `GET /api/v1/user-groups/{id}/members`: List all members of a specific user group. * `POST /api/v1/user-groups/{id}/members`: Add a user to a specific user group. * `DELETE /api/v1/user-groups/{id}/members/{userId}`: Remove a user from a specific user group. **Implementation Notes:** * Create a new file: `server/src/main/kotlin/eu/torvian/chatbot/server/routes/configureUserGroupRoutes.kt` * Utilize the existing [UserGroupService](psi_element://eu.torvian.chatbot.server.service.core.UserGroupService) for business logic. * Ensure proper authentication (`AuthSchemes.USER_JWT`) and authorization (e.g., `MANAGE_USER_GROUPS` permission for CRUD operations). --- #### Priority 2: Resource Access Management Endpoints ⚠️ HIGH **Estimated Duration:** 2-3 days **Description:** Implement API endpoints to grant, revoke, and query access for user groups to providers, models, and settings. This is the core functionality for resource sharing. **Missing Routes to Implement:** * `POST /api/v1/providers/{id}/access`: Grant a specific access mode (e.g., READ, WRITE) to a user group for a provider. * `DELETE /api/v1/providers/{id}/access`: Revoke a specific access mode from a user group for a provider. * `GET /api/v1/providers/{id}/access`: List all user groups that have any access to a provider, along with their access modes. * *(Repeat the above three routes for `/api/v1/models/{id}/access`)* * *(Repeat the above three routes for `/api/v1/settings/{id}/access`)* **Implementation Notes:** * Add these routes to the existing `configureProviderRoutes.kt`, `configureModelRoutes.kt`, and `configureSettingsRoutes.kt` files. * Introduce new service-level methods (e.g., in `LlmProviderService`, `LlmModelService`, `ModelSettingsService`) to wrap the [ProviderAccessDao](psi_element://eu.torvian.chatbot.server.dao.ProviderAccessDao), [ModelAccessDao](psi_element://eu.torvian.chatbot.server.dao.ModelAccessDao), and [SettingsAccessDao](psi_element://eu.torvian.chatbot.server.dao.SettingsAccessDao) operations. * Ensure proper authorization checks using the respective [ResourceAuthorizer](psi_element://eu.torvian.chatbot.server.service.authorization.ResourceAuthorizer) implementations. --- #### Priority 3: Convenience Endpoints (Make Public/Private) 📊 MEDIUM **Estimated Duration:** 1 day **Description:** Implement convenience endpoints to easily toggle the public/private status of resources. These endpoints will internally use the grant/revoke access logic with the "[All Users](psi_element://eu.torvian.chatbot.common.api.CommonUserGroups#ALL_USERS)" group. **Missing Routes to Implement:** * `POST /api/v1/providers/{id}/make-public`: Grant `READ` access to the "[All Users](psi_element://eu.torvian.chatbot.common.api.CommonUserGroups#ALL_USERS)" group for a provider. * `POST /api/v1/providers/{id}/make-private`: Revoke `READ` access from the "[All Users](psi_element://eu.torvian.chatbot.common.api.CommonUserGroups#ALL_USERS)" group for a provider. * `GET /api/v1/providers/{id}/is-public`: Check if a provider is public (i.e., "[All Users](psi_element://eu.torvian.chatbot.common.api.CommonUserGroups#ALL_USERS)" group has `READ` access). * *(Repeat the above three routes for `/api/v1/models/{id}`)* * *(Repeat the above three routes for `/api/v1/settings/{id}`)* **Implementation Notes:** * Add these routes to the existing route configuration files. * Introduce new service methods (e.g., `makeProviderPublic`, `makeProviderPrivate`, `isProviderPublic`) that leverage the [UserGroupService](psi_element://eu.torvian.chatbot.server.service.core.UserGroupService) to get the "[All Users](psi_element://eu.torvian.chatbot.common.api.CommonUserGroups#ALL_USERS)" group and then call the resource access management service methods. --- #### Priority 4: Ownership Information Endpoints 📊 MEDIUM **Estimated Duration:** 0.5 day **Description:** Implement endpoints to retrieve the owner information for a given resource. **Missing Routes to Implement:** * `GET /api/v1/providers/{id}/owner`: Get the user details of the owner of a provider. * `GET /api/v1/models/{id}/owner`: Get the user details of the owner of a model. * `GET /api/v1/settings/{id}/owner`: Get the user details of the owner of a settings profile. **Implementation Notes:** * Add these routes to the existing route configuration files. * Introduce new service methods (e.g., `getProviderOwner`, `getModelOwner`, `getSettingsOwner`) that use the respective [Ownership DAOs](psi_element://eu.torvian.chatbot.server.dao.ProviderOwnershipDao) to retrieve the owner ID and then fetch user details from the `UserService`. --- ### Acceptance Criteria * All specified API endpoints are implemented and accessible. * Endpoints adhere to Ktor's authentication (`AuthSchemes.USER_JWT`) and authorization standards. * Appropriate service-level methods are created to encapsulate business logic. * All new endpoints are covered by unit and/or integration tests. * Error handling is consistent (e.g., using `Either` for results and `call.respondEither`). --- ### Labels `backend`, `api`, `feature`, `priority: high`, `phase3`