1e84df9769
All checks were successful
CI / go-lint (push) Has been skipped
CI / python-lint (push) Has been skipped
CI / nodejs-lint (push) Has been skipped
CI / test-go-ai-compliance (push) Successful in 32s
CI / test-python-backend-compliance (push) Successful in 30s
CI / test-python-document-crawler (push) Successful in 21s
CI / test-python-dsms-gateway (push) Successful in 18s
6-Phasen-Implementation fuer cloud-faehiges, mandantenfaehiges Compliance SDK:
Phase 1: Multi-Tenancy Fix
- Shared tenant_utils.py Dependency (UUID-Validierung, kein "default" mehr)
- VVT tenant_id Column + tenant-scoped Queries
- DSFA/Vendor DEFAULT_TENANT_ID von "default" auf UUID migriert
- Migration 035
Phase 2: Stammdaten-Erweiterung
- Company Profile um JSONB-Felder erweitert (processing_systems, ai_systems, technical_contacts)
- Regulierungs-Flags (NIS2, AI Act, ISO 27001)
- GET /template-context Endpoint
- Migration 036
Phase 3: Dokument-Versionierung
- 5 Versions-Tabellen (DSFA, VVT, TOM, Loeschfristen, Obligations)
- Shared versioning_utils.py Helper
- /{id}/versions Endpoints auf allen 5 Dokumenttypen
- Migration 037
Phase 4: Change-Request System
- Zentrale CR-Inbox mit CRUD + Accept/Reject/Edit Workflow
- Regelbasierte CR-Engine (VVT DPIA → DSFA CR, Datenkategorien → Loeschfristen CR)
- Audit-Trail
- Migration 038
Phase 5: Dokumentengenerierung
- 5 Template-Generatoren (DSFA, VVT, TOM, Loeschfristen, Obligations)
- Preview + Apply Endpoints (erzeugt CRs, keine direkten Dokumente)
Phase 6: Frontend-Integration
- Change-Request Inbox Page mit Stats, Filtern, Modals
- VersionHistory Timeline-Komponente
- SDKSidebar CR-Badge (60s Polling)
- Company Profile: 2 neue Wizard-Steps + "Dokumente generieren" CTA
Docs: 5 neue MkDocs-Seiten, CLAUDE.md aktualisiert
Tests: 97 neue Tests (alle bestanden)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
61 lines
1.8 KiB
Markdown
61 lines
1.8 KiB
Markdown
# Multi-Tenancy
|
|
|
|
Das Compliance SDK ist vollstaendig mandantenfaehig. Jeder Tenant hat isolierte Daten — kein Tenant kann auf Daten eines anderen zugreifen.
|
|
|
|
## Tenant-ID
|
|
|
|
- Format: UUID v4 (z.B. `9282a473-5c95-4b3a-bf78-0ecc0ec71d3e`)
|
|
- Der String `"default"` wird NICHT mehr akzeptiert
|
|
- Validierung via Regex in `tenant_utils.py`
|
|
|
|
## Shared Tenant Middleware
|
|
|
|
`compliance/api/tenant_utils.py` stellt eine zentrale FastAPI-Dependency:
|
|
|
|
```python
|
|
from compliance.api.tenant_utils import get_tenant_id
|
|
|
|
@router.get("/example")
|
|
async def example(tid: str = Depends(get_tenant_id)):
|
|
# tid ist validierte UUID
|
|
...
|
|
```
|
|
|
|
### Resolution-Reihenfolge
|
|
|
|
1. `X-Tenant-ID` HTTP-Header
|
|
2. `tenant_id` Query-Parameter
|
|
3. `DEFAULT_TENANT_ID` Umgebungsvariable
|
|
4. Fallback: `9282a473-5c95-4b3a-bf78-0ecc0ec71d3e`
|
|
|
|
## Migration 035: VVT Tenant Isolation
|
|
|
|
- `compliance_vvt_activities`, `compliance_vvt_organization`, `compliance_vvt_audit_log`: `tenant_id VARCHAR(255) NOT NULL` hinzugefuegt
|
|
- Bestehende Daten auf Standard-UUID backfilled
|
|
- UNIQUE-Constraint `(tenant_id, vvt_id)` statt globalem `vvt_id`
|
|
- DSFA/Vendor: `"default"` → UUID migriert
|
|
|
|
## Betroffene Module
|
|
|
|
| Modul | Aenderung |
|
|
|-------|-----------|
|
|
| VVT | `tenant_id` Column + Query-Filter auf alle Endpoints |
|
|
| DSFA | `DEFAULT_TENANT_ID` von `"default"` auf UUID |
|
|
| Vendor Compliance | `DEFAULT_TENANT_ID` von `"default"` auf UUID |
|
|
| Change-Requests | Nativ mit `tenant_id` |
|
|
| Versionierung | Nativ mit `tenant_id` |
|
|
| Company Profile | Nativ mit `tenant_id` |
|
|
|
|
## Frontend-Proxy
|
|
|
|
Der Next.js-Proxy setzt automatisch den `X-Tenant-ID` Header:
|
|
|
|
```typescript
|
|
headers['X-Tenant-ID'] = clientTenantId || process.env.DEFAULT_TENANT_ID || '9282a473-...'
|
|
```
|
|
|
|
## Tests
|
|
|
|
- 20 Tests in `test_vvt_tenant_isolation.py`
|
|
- UUID-Validierung, Header-/Query-Precedence, Model-Column-Checks, Route-Isolation
|