adapted feature architecture trustee

This commit is contained in:
ValueOn AG 2026-01-24 09:43:35 +01:00
parent 8fa4c870c7
commit b94695e70e

View file

@ -2,10 +2,32 @@
## Übersicht ## Übersicht
Dieses Dokument beschreibt die **Zwei-Stufen-RBAC-Architektur** für das Trustee Feature und beantwortet die Frage, ob das Gateway bereit für die UI-Entwicklung ist. Dieses Dokument beschreibt die **vereinfachte RBAC-Architektur** für das Trustee Feature.
**Erstellungsdatum**: 2026-01-23 **Erstellungsdatum**: 2026-01-23
**Status**: Review **Letzte Änderung**: 2026-01-24
**Status**: Aktuell
---
## WICHTIG: Architektur-Änderung (2026-01-24)
### Feature-Instanz = Organisation
Die ursprüngliche Architektur sah vor, dass innerhalb einer Feature-Instanz mehrere "Organisationen" (Kunden) verwaltet werden. **Dies wurde geändert:**
- **Neu**: Eine Feature-Instanz repräsentiert **eine** Organisation (z.B. "SOHA Treuhand")
- **Entfernt**: `TrusteeOrganisation`, `TrusteeContract`, `TrusteeRole`, `TrusteeAccess`
- **Beibehalten**: `TrusteePosition`, `TrusteeDocument`, `TrusteePositionDocument`
### Vereinfachtes Datenmodell
```
Feature-Instanz (= Organisation, z.B. "SOHA Treuhand")
└── TrusteePosition (Buchungspositionen, Konten)
└── TrusteeDocument (Belege, Berichte)
└── TrusteePositionDocument (Zuordnung Position ↔ Dokument)
```
--- ---
@ -20,7 +42,7 @@ Dieses Dokument beschreibt die **Zwei-Stufen-RBAC-Architektur** für das Trustee
| **Routes** | `routeFeatureTrustee.py` | ✅ Komplett | | **Routes** | `routeFeatureTrustee.py` | ✅ Komplett |
| **Interface** | `interfaceFeatureTrustee.py` | ✅ Komplett | | **Interface** | `interfaceFeatureTrustee.py` | ✅ Komplett |
| **Datamodel** | `datamodelFeatureTrustee.py` | ✅ Komplett | | **Datamodel** | `datamodelFeatureTrustee.py` | ✅ Komplett |
| **Feature-RBAC** | Via `TrusteeAccess` Tabelle | ✅ Implementiert | | **RBAC** | Via System-Level AccessRules | ✅ Implementiert |
### 1.2 Verfügbare API-Endpoints ### 1.2 Verfügbare API-Endpoints
@ -28,56 +50,43 @@ Alle Endpoints verwenden das URL-Pattern: `/api/trustee/{instanceId}/...`
| Endpoint-Gruppe | Basis-Route | CRUD | Options | | Endpoint-Gruppe | Basis-Route | CRUD | Options |
|-----------------|-------------|------|---------| |-----------------|-------------|------|---------|
| Organisations | `/api/trustee/{instanceId}/organisations` | ✅ | ✅ |
| Roles | `/api/trustee/{instanceId}/roles` | ✅ | ✅ |
| **Access** | `/api/trustee/{instanceId}/access` | ✅ | - |
| Contracts | `/api/trustee/{instanceId}/contracts` | ✅ | ✅ |
| Documents | `/api/trustee/{instanceId}/documents` | ✅ | ✅ | | Documents | `/api/trustee/{instanceId}/documents` | ✅ | ✅ |
| Positions | `/api/trustee/{instanceId}/positions` | ✅ | ✅ | | Positions | `/api/trustee/{instanceId}/positions` | ✅ | ✅ |
| Position-Documents | `/api/trustee/{instanceId}/position-documents` | ✅ | - | | Position-Documents | `/api/trustee/{instanceId}/position-documents` | ✅ | - |
| **Instance-Roles** | `/api/trustee/{instanceId}/instance-roles` | ✅ | - |
| **User Options** | `/api/users/options` | - | ✅ | | **User Options** | `/api/users/options` | - | ✅ |
### 1.3 Wichtige Änderung vs. UI-Spezifikation ### 1.3 Frontend Views
Die ursprüngliche UI-Spezifikation (`doc_trustee_feature_ui_specification.md`) verwendet URLs wie: | View | Pfad | Beschreibung |
``` |------|------|--------------|
/api/trustee/organisations/ | Dashboard | `/dashboard` | Übersicht |
``` | Positionen | `/positions` | Buchungspositionen verwalten |
| Dokumente | `/documents` | Belege/Berichte verwalten |
Die **aktuelle Implementierung** verwendet: | Zuordnungen | `/position-documents` | Position ↔ Dokument Zuordnungen |
``` | Rollen & Rechte | `/instance-roles` | Instanz-Rollen verwalten (nur Admin) |
/api/trustee/{instanceId}/organisations/
```
**Grund**: Multi-Tenancy - mehrere Treuhandbüros (Feature-Instanzen) pro Mandate möglich.
--- ---
## 2. Architektur: Zwei-Stufen-RBAC für Features ## 2. RBAC-Architektur (Vereinfacht)
### 2.1 Das Problem ### 2.1 Nur System-Level RBAC
Ein Treuhandbüro (Feature-Instanz) verwaltet mehrere Kunden (Organisationen). Jeder Mitarbeiter soll nur die Kunden sehen, für die er zuständig ist: Da die Feature-Instanz selbst die Organisation repräsentiert, ist **kein Feature-internes RBAC** mehr nötig.
- **User A** → Kunde 1, Kunde 2
- **User B** → Kunde 2, Kunde 3
- **User C** → Alle Kunden (Admin)
Dies erfordert eine **Feature-interne Isolation**, die über das System-RBAC hinausgeht.
### 2.2 Lösung: Zwei-Stufen-RBAC
``` ```
┌─────────────────────────────────────────────────────────────────────────┐ ┌─────────────────────────────────────────────────────────────────────────┐
│ STUFE 1: SYSTEM-RBAC │ SYSTEM-RBAC (Basis-Level) │
│ (Mandate + Feature Instance Zugang) │ │ (Mandate + Feature Instance Zugang) │
├─────────────────────────────────────────────────────────────────────────┤ ├─────────────────────────────────────────────────────────────────────────┤
│ │ │ │
│ User ──► UserMandate ──► Mandate │ │ User ──► UserMandate ──► Mandate │
│ │ │ │ │ │
│ └──► FeatureAccess ──► FeatureInstance (Treuhandbüro) │ └──► FeatureAccess ──► FeatureInstance (= Organisation)
│ │ │ │ │ │
│ └── Rollen: feature-admin, feature-user │ │ └── Role (trustee-admin, trustee-accountant, trustee-client)│
│ │ │
│ └── AccessRules (UI, DATA, RESOURCE) │
│ │ │ │
│ Frage: Hat der User überhaupt Zugang zu diesem Feature? │ │ Frage: Hat der User überhaupt Zugang zu diesem Feature? │
│ │ │ │