From b94695e70ee65a34d192be8b2fd3e7e3d6e1f71c Mon Sep 17 00:00:00 2001 From: ValueOn AG Date: Sat, 24 Jan 2026 09:43:35 +0100 Subject: [PATCH] adapted feature architecture trustee --- .../trustee_feature_rbac_architecture.md | 75 +++++++++++-------- 1 file changed, 42 insertions(+), 33 deletions(-) diff --git a/implementation/trustee_feature_rbac_architecture.md b/implementation/trustee_feature_rbac_architecture.md index 983fa2e..ef1c13f 100644 --- a/implementation/trustee_feature_rbac_architecture.md +++ b/implementation/trustee_feature_rbac_architecture.md @@ -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? │ │ │