LightRAG/docs/archives/action_plan/04-docker-multi-tenant-testing.md
Raphael MANSUY 2b292d4924
docs: Enterprise Edition & Multi-tenancy attribution (#5)
* Remove outdated documentation files: Quick Start Guide, Apache AGE Analysis, and Scratchpad.

* Add multi-tenant testing strategy and ADR index documentation

- Introduced ADR 008 detailing the multi-tenant testing strategy for the ./starter environment, covering compatibility and multi-tenant modes, testing scenarios, and implementation details.
- Created a comprehensive ADR index (README.md) summarizing all architecture decision records related to the multi-tenant implementation, including purpose, key sections, and reading paths for different roles.

* feat(docs): Add comprehensive multi-tenancy guide and README for LightRAG Enterprise

- Introduced `0008-multi-tenancy.md` detailing multi-tenancy architecture, key concepts, roles, permissions, configuration, and API endpoints.
- Created `README.md` as the main documentation index, outlining features, quick start, system overview, and deployment options.
- Documented the LightRAG architecture, storage backends, LLM integrations, and query modes.
- Established a task log (`2025-01-21-lightrag-documentation-log.md`) summarizing documentation creation actions, decisions, and insights.
2025-12-04 18:09:15 +08:00

61 lines
2.7 KiB
Markdown

# Action Plan: Multi-Tenant Docker Testing & UI Updates
## Objective
Enable a seamless multi-tenant testing environment using Docker and update the WebUI to fully support the new implicit tenant context architecture.
## Phase 1: Docker Environment (`starter/`)
### 1.1 Review & Fix `docker-compose.yml`
- **Current Status**: `starter/docker-compose.yml` defines a full stack (Postgres, Redis, API, WebUI).
- **Action**:
- Verify build contexts are correct relative to `starter/` directory.
- Ensure `lightrag-api` and `lightrag-webui` services are building from the latest code.
- Check network configuration to ensure containers can communicate.
### 1.2 Create Testing Script (`starter/test_multi_tenant.sh`)
- **Goal**: Automate the spin-up and verification process.
- **Steps**:
1. Teardown existing containers and volumes (`docker-compose down -v`).
2. Build and start services (`docker-compose up -d --build`).
3. Wait for services to be healthy.
4. Execute `scripts/init_demo_tenants.py` to populate data.
5. Run `curl` integration tests to verify tenant isolation (e.g., Tenant A cannot see Tenant B's data).
## Phase 2: WebUI Analysis & Updates (`lightrag_webui/`)
### 2.1 Analyze Existing UI
- **Current State**: The UI likely uses the old API client or hardcoded paths.
- **Needs Removal**:
- Direct usage of `tenantId` in URL paths in components (e.g., `axios.get('/tenants/${id}/...')`).
- **Needs Update**:
- **API Client**: Already updated in `src/api/tenant.ts`.
- **State Management**: Ensure a global `useTenant` hook or store exists to manage the currently selected `tenantId`.
- **Interceptors**: Add an Axios interceptor to automatically inject `X-Tenant-ID` header from the global state into all requests.
- **Components**: Update `KnowledgeBaseList`, `DocumentList`, etc., to remove `tenantId` props if they are just passing it down for API calls.
### 2.2 Implementation Steps
- [ ] **Step 1**: Create/Update `TenantContext` or Store to manage `currentTenant`.
- [ ] **Step 2**: Configure Axios interceptor in `src/api/client.ts` (or similar) to attach `X-Tenant-ID`.
- [ ] **Step 3**: Update `TenantSelector` component to set the global `currentTenant`.
- [ ] **Step 4**: Refactor main views to rely on the global tenant context instead of URL params for tenant ID.
## Phase 3: Execution & Verification
### 3.1 Run the Test Suite
- Execute `starter/test_multi_tenant.sh`.
- Verify logs show successful data population.
- Verify UI allows switching tenants and shows correct data for each.
### 3.2 Manual Verification
- Open `http://localhost:3000`.
- Login/Select "Acme Corp".
- Verify "Production KB" is visible.
- Switch to "TechStart".
- Verify "Main KB" is visible and "Production KB" is GONE.