adapted feature architecture trustee
This commit is contained in:
ValueOn AG
parent
8fa4c870c7
commit
b94695e70e
1 changed files with 42 additions and 33 deletions
|
|
@ -2,10 +2,32 @@
|
|||
|
||||
## Ü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
|
||||
**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 |
|
||||
| **Interface** | `interfaceFeatureTrustee.py` | ✅ Komplett |
|
||||
| **Datamodel** | `datamodelFeatureTrustee.py` | ✅ Komplett |
|
||||
| **Feature-RBAC** | Via `TrusteeAccess` Tabelle | ✅ Implementiert |
|
||||
| **RBAC** | Via System-Level AccessRules | ✅ Implementiert |
|
||||
|
||||
### 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 |
|
||||
|-----------------|-------------|------|---------|
|
||||
| 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` | ✅ | ✅ |
|
||||
| Positions | `/api/trustee/{instanceId}/positions` | ✅ | ✅ |
|
||||
| Position-Documents | `/api/trustee/{instanceId}/position-documents` | ✅ | - |
|
||||
| **Instance-Roles** | `/api/trustee/{instanceId}/instance-roles` | ✅ | - |
|
||||
| **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:
|
||||
```
|
||||
/api/trustee/organisations/
|
||||
```
|
||||
|
||||
Die **aktuelle Implementierung** verwendet:
|
||||
```
|
||||
/api/trustee/{instanceId}/organisations/
|
||||
```
|
||||
|
||||
**Grund**: Multi-Tenancy - mehrere Treuhandbüros (Feature-Instanzen) pro Mandate möglich.
|
||||
| View | Pfad | Beschreibung |
|
||||
|------|------|--------------|
|
||||
| Dashboard | `/dashboard` | Übersicht |
|
||||
| Positionen | `/positions` | Buchungspositionen verwalten |
|
||||
| Dokumente | `/documents` | Belege/Berichte verwalten |
|
||||
| Zuordnungen | `/position-documents` | Position ↔ Dokument Zuordnungen |
|
||||
| Rollen & Rechte | `/instance-roles` | Instanz-Rollen verwalten (nur Admin) |
|
||||
|
||||
---
|
||||
|
||||
## 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:
|
||||
|
||||
- **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
|
||||
Da die Feature-Instanz selbst die Organisation repräsentiert, ist **kein Feature-internes RBAC** mehr nötig.
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ STUFE 1: SYSTEM-RBAC │
|
||||
│ SYSTEM-RBAC (Basis-Level) │
|
||||
│ (Mandate + Feature Instance Zugang) │
|
||||
├─────────────────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ 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? │
|
||||
│ │
|
||||
|
|
|
|||
Loading…
Reference in a new issue