Files
Benjamin Admin 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
feat(sdk): Multi-Tenancy, Versionierung, Change-Requests, Dokumentengenerierung (Phase 1-6)
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>
2026-03-07 14:12:34 +01:00

126 lines
3.9 KiB
Markdown

# Change-Request System (CP-CR)
Das Change-Request-System ist die zentrale Inbox fuer alle Dokumentenaenderungen im Compliance SDK. Statt Dokumente direkt zu erstellen oder zu aendern, werden alle Aenderungen als Change-Requests vorgeschlagen und muessen explizit angenommen oder abgelehnt werden.
## Architektur
```mermaid
graph TD
A[Trigger-Event] --> B[Change-Request Engine]
B --> C[CR-Inbox pending]
C --> D{Entscheidung}
D -->|Accept| E[Version erstellen]
D -->|Edit & Accept| F[Bearbeiten + Version]
D -->|Reject| G[Ablehnen + Begruendung]
E --> H[Audit-Log]
F --> H
G --> H
```
## API-Endpoints
| Methode | Pfad | Beschreibung |
|---------|------|--------------|
| `GET` | `/change-requests` | Liste (Filter: status, doc_type, priority) |
| `GET` | `/change-requests/stats` | Statistik: pending, critical, accepted, rejected |
| `GET` | `/change-requests/{id}` | Detail mit Audit-Log |
| `POST` | `/change-requests` | Manuell erstellen |
| `POST` | `/change-requests/{id}/accept` | Aenderung uebernehmen, Version erstellen |
| `POST` | `/change-requests/{id}/reject` | Ablehnen mit Begruendung |
| `POST` | `/change-requests/{id}/edit` | Vorschlag bearbeiten und annehmen |
| `DELETE` | `/change-requests/{id}` | Soft-Delete |
## Status-Workflow
```
pending --> accepted
pending --> rejected
pending --> edited_and_accepted
```
## Prioritaeten
- `critical` — Sofortige Aktion erforderlich
- `high` — Wichtig, zeitnah bearbeiten
- `normal` — Standard-Prioritaet
- `low` — Kann warten
## Trigger-Typen
| Trigger | Erzeugte Change-Requests |
|---------|--------------------------|
| `generation` | Automatisch aus Stammdaten generiert |
| `vvt_dpia` | VVT-Aktivitaet mit dpia_required=true → DSFA CR |
| `vvt_data_category` | Neue Datenkategorie → Loeschfristen CR |
| `use_case_risk` | Use Case mit hohem Risiko → DSFA CR |
| `use_case_ai` | Use Case mit KI → DSFA Sektion-Update CR |
| `manual` | Manuell erstellt |
## Change-Request Engine
Die Engine (`change_request_engine.py`) generiert automatisch Change-Requests bei bestimmten Trigger-Events:
### VVT-Trigger
```python
generate_change_requests_for_vvt(db, tenant_id, activity, user)
```
- Wenn `dpia_required=true`: DSFA-CR wird erstellt
- Fuer jede neue Datenkategorie: Loeschfristen-CR wird erstellt
### Use-Case-Trigger
```python
generate_change_requests_for_use_case(db, tenant_id, use_case, user)
```
- Bei `risk_level` high/critical: DSFA-CR
- Bei KI-Involvement: DSFA-Sektions-Update-CR
## Frontend
Die Change-Request Inbox ist unter `/sdk/change-requests` erreichbar:
- Stats-Bar mit Zahlen (pending, critical, accepted, rejected)
- Filter nach Status und Dokumenttyp
- Card-Liste mit Trigger-Badge, Titel, Prioritaet
- Accept/Edit/Reject Modals
- 60s Auto-Refresh
## Datenbank
### Migration 038
```sql
CREATE TABLE compliance_change_requests (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id VARCHAR(255) NOT NULL,
trigger_type VARCHAR(50) NOT NULL,
target_document_type VARCHAR(50),
target_document_id UUID,
target_section VARCHAR(100),
proposal_title VARCHAR(500) NOT NULL,
proposal_body TEXT,
proposed_changes JSONB DEFAULT '{}',
status VARCHAR(30) DEFAULT 'pending',
priority VARCHAR(20) DEFAULT 'normal',
decided_by VARCHAR(255),
decided_at TIMESTAMPTZ,
rejection_reason TEXT,
created_by VARCHAR(255) DEFAULT 'system',
created_at TIMESTAMPTZ DEFAULT NOW(),
deleted_at TIMESTAMPTZ
);
CREATE TABLE compliance_change_request_audit (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
change_request_id UUID REFERENCES compliance_change_requests(id),
action VARCHAR(50) NOT NULL,
performed_by VARCHAR(255),
before_state JSONB,
after_state JSONB,
created_at TIMESTAMPTZ DEFAULT NOW()
);
```
## Tests
- 26 Tests in `test_change_request_routes.py`
- Schema-Validierung, Engine-Regeln, Route-Registrierung