579 lines
24 KiB
Markdown
579 lines
24 KiB
Markdown
# RBAC Zugriffskonzept (Katalog + Seiten + Endpoints)
|
|
|
|
## Kontext aus dem Codebestand (aktueller Stand)
|
|
|
|
- RBAC-Regeln und Rollen existieren bereits mit immutable Kontextfeldern und AccessRule-Unterstuetzung fuer DATA/UI/RESOURCE. Siehe `AccessRuleContext`, `Role`, `AccessRule` in:
|
|
```
|
|
21:116:gateway/modules/datamodels/datamodelRbac.py
|
|
class AccessRuleContext(str, Enum):
|
|
DATA = "DATA"
|
|
UI = "UI"
|
|
RESOURCE = "RESOURCE"
|
|
...
|
|
class AccessRule(BaseModel):
|
|
roleId: str
|
|
context: AccessRuleContext
|
|
item: Optional[str]
|
|
view: bool
|
|
read: Optional[AccessLevel]
|
|
create: Optional[AccessLevel]
|
|
update: Optional[AccessLevel]
|
|
delete: Optional[AccessLevel]
|
|
```
|
|
- RBAC-Endpunkte fuer Permissions und Access Rules existieren bereits (Access Rules sind SysAdmin-only):
|
|
```
|
|
35:214:gateway/modules/routes/routeRbac.py
|
|
@router.get("/permissions")
|
|
@router.get("/permissions/all")
|
|
@router.get("/rules")
|
|
```
|
|
- Mandantenzuordnung von Benutzern/Rollen laeuft ueber `/api/mandates/{mandateId}/users` und die Junction-Tabellen `UserMandateRole` (Mandanten-Kontext) und `FeatureAccessRole` (Feature-Instanz-Kontext):
|
|
```
|
|
15:149:gateway/modules/datamodels/datamodelMembership.py
|
|
class UserMandateRole(BaseModel):
|
|
userMandateId: str
|
|
roleId: str
|
|
...
|
|
class FeatureAccessRole(BaseModel):
|
|
featureAccessId: str
|
|
roleId: str
|
|
```
|
|
- Im Frontend existieren Admin-Seiten fuer Benutzer-Mandant-Mitgliedschaften und Mandanten-Rollen:
|
|
```
|
|
1:120:frontend_nyla/src/pages/admin/AdminUserMandatesPage.tsx
|
|
1:185:frontend_nyla/src/pages/admin/AdminMandateRolesPage.tsx
|
|
```
|
|
|
|
Damit ist klar:
|
|
- Zugriffregeln existieren bereits (view + CRUD mit none/my/group/all).
|
|
- Fehlend ist ein **Katalog + Editor-UI** fuer Objektregeln (DATA/UI/RESOURCE).
|
|
|
|
## Entscheidungen / Antworten zu Inputs
|
|
|
|
1) **Shared Katalog-Location (Gateway):**
|
|
- Es gibt aktuell keinen gemeinsamen RBAC-Objektkatalog in datamodels. Datamodels definieren nur Schema.
|
|
- Ziel-Location: `gateway/modules/security/rbacCatalog/` (Service-Layer), nicht `datamodels`.
|
|
- DATA-Objekte koennen on-the-fly aus Modellen/Attributen abgeleitet werden, ohne Persistenz.
|
|
- UI- und RESOURCE-Objekte brauchen explizite Registry-Eintraege, persistent in einer Katalog-Tabelle, dann ueber Gateway-Endpunkte abrufbar.
|
|
- Feature-Initialisierung im Gateway registriert die UI/RESOURCE-Keys. Die Admin-UI zeigt alle persistierten Katalogobjekte (keine Filterung nach Registrierungsstatus).
|
|
- Persistenz ist Pflicht, um Regeln nicht zu verlieren, wenn Features entfernt oder deaktiviert werden.
|
|
|
|
2) **Admin-Seite fuer Mandantenverwaltung: gleich wie Rollen-Zuordnung?**
|
|
- Mandanten-CRUD getrennt von Rollen-Zuordnung.
|
|
- Heute: Mandanten-CRUD ist SysAdmin-only (`/api/mandates`), Rollen-Zuordnung ist Mandanten-Admin (`/api/mandates/{mandateId}/users`).
|
|
- Ziel: separate **AdminMandatesPage** (SysAdmin), **AdminUserMandatesPage** fuer Rollen-Zuordnung.
|
|
- Zusaetzlich: **AdminRbacRulesPage** (Feature-Instanz-Admin) fuer Objektregeln.
|
|
|
|
3) **Registry-Eigentum und Quellen:**
|
|
- Feature-Initialisierung im Gateway definiert alle UI/RESOURCE-Objekte der Features.
|
|
- Frontend registriert keine Feature-UI-Objekte.
|
|
- System-UI-Objekte werden direkt im Backend definiert (keine UI-Abhaengigkeit).
|
|
|
|
4) **UI-Permissions:**
|
|
- UI-Kontext nutzt nur `view`.
|
|
- Kein create/update/delete fuer UI-Kontext.
|
|
|
|
5) **Katalog-Scope:**
|
|
- Der Katalog enthaelt alle Objekte (global + mandate + feature instance).
|
|
|
|
6) **Bootstrap-Scope (interfaceBootstrap.py):**
|
|
- Bootstrap laeuft nur, wenn die Datenbank leer ist.
|
|
- Bootstrap erzeugt nur System-RBAC (Root-Mandant, Admin/Event-User, globale Rollen, Basisregeln).
|
|
- Bootstrap definiert keine Feature-Rollen oder Feature-Zugriffsregeln.
|
|
- System-UI-Objekte sind im Backend definiert und koennen im Bootstrap registriert werden.
|
|
|
|
## Zielarchitektur
|
|
|
|
### A) RBAC Objektkatalog (shared im Gateway)
|
|
|
|
**Ziel:** Ein einziger Objektbaum fuer DATA / UI / RESOURCE, mit Mandant + Feature-Instanz-Kontext.
|
|
|
|
**Quelle je Objekttyp:**
|
|
- **DATA**: abgeleitet aus Model-Metadaten (Tabellen + Felder).
|
|
- **UI**: Registry aus Feature-Initialisierung plus backend-definierte System-UI-Objekte.
|
|
- **RESOURCE**: Registry aus Feature-Initialisierung.
|
|
|
|
**Persistenz:**
|
|
- Kleine Katalog-Tabelle `RbacObject` (oder aehnlich) fuer UI/RESOURCE.
|
|
- DATA-Objekte nicht speichern; on-demand generieren.
|
|
- Nicht registrierte Objekte bleiben im Katalog und bleiben selektierbar; keine Filterung nach Registrierung.
|
|
|
|
**Model (gateway/modules/datamodels/datamodelRbacCatalog.py):**
|
|
- `id`
|
|
- `objectKey` (unique, z.B. `ui.feature.trustee.contracts.tab.documents`)
|
|
- `context` (DATA | UI | RESOURCE)
|
|
- `featureCode` (z.B. `trustee`)
|
|
- `featureInstanceId` (nullable)
|
|
- `mandateId` (nullable)
|
|
- `label` (multilingual, optional)
|
|
- `meta` (JSON, optional, z.B. Endpoint-Info oder UI-Hints)
|
|
|
|
**Registry-Logik (gateway/modules/security/rbacCatalog/catalogService.py):**
|
|
- `getDataCatalog(mandateId, featureInstanceId)` -> aus Modellen ableiten:
|
|
- `data.table.<table>`
|
|
- `data.table.<table>.<field>`
|
|
- `getUiCatalog(mandateId, featureInstanceId, featureCode)` -> aus `RbacObject` (UI-Kontext)
|
|
- `getResourceCatalog(mandateId, featureInstanceId, featureCode)` -> aus `RbacObject` (RESOURCE-Kontext)
|
|
- `getCatalog(...)` -> zusammenfuehren; alle Objekte (global + mandate + feature instance)
|
|
|
|
**ObjectKey-Konvention:**
|
|
- DATA:
|
|
- `data.table.<table>`
|
|
- `data.table.<table>.<field>`
|
|
- UI:
|
|
- `ui.feature.<featureCode>.<area>.<element>`
|
|
- Beispiel: `ui.feature.trustee.contracts.tab.documents`
|
|
- RESOURCE:
|
|
- `resource.feature.<featureCode>.<endpoint>`
|
|
- Beispiel: `resource.feature.trustee.contracts.create`
|
|
|
|
### B) RBAC Rules Editor (neue Admin-Seite)
|
|
|
|
**Seitenname:** `AdminRbacRulesPage`
|
|
**Zielgruppe:** Feature-Instanz-Admin
|
|
**Route:** `/admin/feature-instances/:featureInstanceId/rbac`
|
|
**Navigation:** Feature-Instanz-Seiten “Rollen” + “Zugriffe” ersetzen durch:
|
|
- “Feature-Benutzer” (bestehende User/Rollen-Zuordnung)
|
|
- “Zugriffe (RBAC)” (neue Seite fuer Objektregeln)
|
|
|
|
**Layout:**
|
|
- Links: Objektbaum (DATA / UI / RESOURCE)
|
|
- Oben: Rollen-Auswahl (Feature-Instanz-Rollen)
|
|
- Rechts: Regel-Grid (view/read/create/update/delete mit Scope)
|
|
- UI: nur `view`
|
|
- RESOURCE: view + CRUD mit none/my/group/all
|
|
- DATA: CRUD mit none/my/group/all
|
|
|
|
**Verhalten:**
|
|
- Auswahl eines Objekts zeigt Regeln je Rolle.
|
|
- Aenderungen ueber create/update/delete von AccessRule.
|
|
- Nur Rollen der Feature-Instanz sind auswaehlbar.
|
|
|
|
### C) Backend-Endpunkte (Vorschlag)
|
|
|
|
#### Katalog-Endpunkte
|
|
```
|
|
GET /api/rbac/catalog?featureInstanceId=...&featureCode=...&include=data,ui,resource
|
|
```
|
|
Response:
|
|
```
|
|
{
|
|
"data": [{ "objectKey": "data.table.TrusteeContract", "label": "...", "children": [...] }],
|
|
"ui": [{ "objectKey": "ui.feature.trustee.contracts", "label": "...", "children": [...] }],
|
|
"resource": [{ "objectKey": "resource.feature.trustee.contracts.create", "label": "..." }]
|
|
}
|
|
```
|
|
|
|
```
|
|
POST /api/rbac/catalog/ui
|
|
POST /api/rbac/catalog/resource
|
|
```
|
|
Payload:
|
|
```
|
|
{
|
|
"featureCode": "trustee",
|
|
"featureInstanceId": "optional",
|
|
"mandateId": "optional",
|
|
"objects": [
|
|
{ "objectKey": "ui.feature.trustee.contracts", "label": { "en": "...", "de": "..." }, "meta": {} }
|
|
]
|
|
}
|
|
```
|
|
Notes:
|
|
- Endpunkte registrieren/aktualisieren UI/RESOURCE-Katalogeintraege.
|
|
- DATA-Objekte werden nie gepostet.
|
|
- Admin-UI darf alle persistenten Objekte selektieren.
|
|
|
|
#### AccessRule-Endpunkte (bestehend, aber erweitert)
|
|
```
|
|
GET /api/rbac/rules?roleId=...&context=UI&item=ui.feature.trustee.contracts
|
|
POST /api/rbac/rules
|
|
PUT /api/rbac/rules/{ruleId}
|
|
DELETE /api/rbac/rules/{ruleId}
|
|
```
|
|
Policy:
|
|
- Nur SysAdmin darf Regeln verwalten.
|
|
|
|
#### Optionale Options-Endpunkte fuer Admin-UI
|
|
```
|
|
GET /api/options/mandate.roles?mandateId=...
|
|
GET /api/options/featureInstance.roles?featureInstanceId=...
|
|
GET /api/options/featureInstances?mandateId=...
|
|
```
|
|
|
|
### D) Enforcement
|
|
- **DATA:** ueber RBAC in der Daten-Schicht.
|
|
- **UI:** Frontend nutzt `getAllPermissions` und blendet aus via `view`.
|
|
- **RESOURCE:** Gateway prueft am Endpoint-Entry.
|
|
|
|
## Implementierungsschritte (high level)
|
|
|
|
1) Katalog-Model + Service im Gateway.
|
|
2) Katalog-Endpunkte in `routeRbacCatalog.py`.
|
|
3) Registry-Producer:
|
|
- Feature-Initialisierung registriert UI/RESOURCE.
|
|
- System-UI-Objekte werden im Backend registriert.
|
|
4) Neue Admin-Seite `AdminRbacRulesPage`.
|
|
5) Feature-Instanz-Navigation anpassen.
|
|
|
|
## Bootstrap-Abgleich (aktuell vs Ziel)
|
|
|
|
**Aktuell (interfaceBootstrap.py):**
|
|
- Root-Mandant, Admin-User, Event-User.
|
|
- Globale Template-Rollen: `admin`, `user`, `viewer`.
|
|
- AccessRules (nur wenn keine existieren):
|
|
- Default DATA rules (item=None).
|
|
- Table-spezifische DATA rules (Mandate, UserInDB, Standard-Tabellen, AuthEvent).
|
|
- UI rules (context=UI, item=None, view=True).
|
|
- RESOURCE rules (context=RESOURCE, item=None, view=True).
|
|
- Feature-Initialisierung und Feature-Template-Rollen.
|
|
- AccessRules fuer Feature-Template-Rollen.
|
|
|
|
**Ziel:**
|
|
- Bootstrap nur System-RBAC, nur bei leerer DB.
|
|
- Feature-Definitionen/Template-Rollen/Feature-Regeln entfernen.
|
|
- Feature-Initialisierung verwaltet Katalog + Feature-Regeln.
|
|
|
|
### Konkrete Aenderungen in `interfaceBootstrap.py`
|
|
|
|
**Aus `initBootstrap()` entfernen:**
|
|
- `initFeatures(db)`
|
|
- `_initFeatureTemplateRoleAccessRules(db)`
|
|
|
|
**Feature-Template-Rollen entfernen:**
|
|
- `_initFeatureTemplateRoles(db)` und alle Aufrufe
|
|
|
|
**Feature-Regeln entfernen:**
|
|
- `_initFeatureTemplateRoleAccessRules(db)` und alle Aufrufe
|
|
|
|
**System-RBAC behalten:**
|
|
- `initRoles()` fuer globale Rollen `admin`, `user`, `viewer`
|
|
- `initRbacRules()` fuer:
|
|
- Default DATA rules
|
|
- Table-spezifische DATA rules
|
|
- UI rules (view)
|
|
- RESOURCE rules (view)
|
|
|
|
**Bootstrap-Guard:**
|
|
- Nur bei leerer DB.
|
|
- System-UI-Objekte im Backend registrieren (Bootstrap oder Startup).
|
|
|
|
## Offene Punkte
|
|
|
|
- Alle Regeln bleiben persistent, bis sie manuell geloescht werden.
|
|
|
|
## Feature-Containerisierung
|
|
|
|
### Ziel
|
|
Jedes Feature in einem eigenen Ordner, damit Features durch Ordner-Praesenz aktiv sind. Jeder Container enthaelt:
|
|
- `datamodelFeatureXxx.py`
|
|
- `interfaceFeatureXxx.py`
|
|
- `routeFeatureXxx.py`
|
|
- main module fuer RBAC-Objekte
|
|
- optionale Helpers
|
|
|
|
### Aktuelle Feature-Dateien
|
|
|
|
**Routes (gateway/modules/routes):**
|
|
- `routeFeatureTrustee.py`
|
|
- `routeFeatureChatbot.py`
|
|
- `routeFeatureChatDynamic.py` (chatworkflow)
|
|
- `routeFeatureNeutralization.py`
|
|
- `routeFeatureRealEstate.py`
|
|
- `routeFeatureWorkflow.py` (automation events)
|
|
- `routeFeatures.py` (Feature/Instance-Management, kein Feature)
|
|
|
|
**Interfaces (gateway/modules/interfaces):**
|
|
- `interfaceDbTrustee.py`
|
|
- `interfaceDbChatbot.py` (shared mit workflow)
|
|
- `interfaceDbRealEstate.py`
|
|
- `interfaceFeatures.py` (Feature/Instance-Management, kein Feature)
|
|
|
|
**Datamodels (gateway/modules/datamodels):**
|
|
- `datamodelTrustee.py`
|
|
- `datamodelChat.py`
|
|
- `datamodelWorkflow.py`
|
|
- `datamodelRealEstate.py`
|
|
- `datamodelNeutralizer.py`
|
|
- `datamodelFeatures.py` (Feature/Instance-Management, kein Feature)
|
|
|
|
**Feature-Logik (gateway/modules/features):**
|
|
- `chatbot/` (mainChatbot.py, eventManager.py, chatbotConstants.py)
|
|
- `realEstate/` (mainRealEstate.py)
|
|
- `neutralizePlayground/` (mainNeutralizePlayground.py)
|
|
|
|
**Nicht-Feature Module (aus features heraus):**
|
|
- `gateway/modules/features/featuresLifecycle.py` -> `gateway/modules/workflows/automation/` (Event Scheduler Handling)
|
|
- `gateway/modules/features/workflow/` -> `gateway/modules/workflows/automation/` (zentrale Workflow Execution Engine)
|
|
- `gateway/modules/features/dynamicOptions/` -> entfernen, dynamische Optionen ueber API-Routen
|
|
|
|
### Zielstruktur pro Feature
|
|
|
|
**trustee** (neu):
|
|
- Move:
|
|
- `modules/routes/routeFeatureTrustee.py`
|
|
- `modules/interfaces/interfaceDbTrustee.py`
|
|
- `modules/datamodels/datamodelTrustee.py`
|
|
- Add:
|
|
- `modules/features/trustee/mainTrustee.py` (RBAC UI/RESOURCE-Katalog)
|
|
- Add main module fuer RBAC-Katalog (falls noch nicht vorhanden)
|
|
|
|
**chatbot**:
|
|
- Move:
|
|
- `modules/routes/routeFeatureChatbot.py`
|
|
- `modules/interfaces/interfaceDbChatbot.py`
|
|
- modules/datamodels/datamodelChatbot.py
|
|
- Keep:
|
|
- `modules/features/chatbot/mainChatbot.py`, Helpers
|
|
- Add main module fuer RBAC-Katalog (falls noch nicht vorhanden)
|
|
|
|
**aichat** (chatworkflow):
|
|
- Move:
|
|
- `modules/routes/routeFeatureChatDynamic.py`
|
|
- `modules/interfaces/interfaceDbChat.py`
|
|
- modules/datamodels/datamodelChat.py
|
|
- Add main module fuer RBAC-Katalog (falls noch nicht vorhanden)
|
|
|
|
**neutralizer** (Rename von neutralizePlayground):
|
|
- Move:
|
|
- `modules/routes/routeFeatureNeutralization.py`
|
|
- `modules/datamodels/datamodelNeutralizer.py`
|
|
- Keep:
|
|
- `modules/features/neutralizePlayground/mainNeutralizePlayground.py` (Rename Ordner zu `neutralizer`)
|
|
- Add main module fuer RBAC-Katalog (falls noch nicht vorhanden)
|
|
|
|
**realestate**:
|
|
- Move:
|
|
- `modules/routes/routeFeatureRealEstate.py`
|
|
- `modules/interfaces/interfaceDbRealEstate.py`
|
|
- `modules/datamodels/datamodelRealEstate.py`
|
|
- Keep:
|
|
- `modules/features/realEstate/mainRealEstate.py`
|
|
- Add main module fuer RBAC-Katalog (falls noch nicht vorhanden)
|
|
|
|
**automation** (neu):
|
|
- Move:
|
|
- `modules/routes/routeDataAutomation.py`
|
|
- `modules/interfaces/interfaceDbAutomation.py` <<- new, to put all automation related interfaces here>>
|
|
- `modules/datamodels/datamodelAutomation.py` <<- new, to put class AutomationDefinition here>>
|
|
- Add main module fuer RBAC-Katalog (falls noch nicht vorhanden)
|
|
|
|
- Neue datamodel/interface/route/main Module
|
|
|
|
### App-Routing als Plug-and-Play
|
|
`gateway/app.py` importiert `routeFeature*.py` aus Feature-Containern.
|
|
Pattern:
|
|
- `from modules.features.<featureCode>.routeFeature<FeatureCode> import router as <featureRouter>`
|
|
- Nur existierende Ordner werden eingebunden.
|
|
- Feature-Ordner loeschen = Feature deaktivieren.
|
|
|
|
### Notwendige Referenz-Updates
|
|
- Imports in `app.py` auf neue Pfade.
|
|
- Alle direkten Imports der alten `modules/routes/routeFeature*.py`.
|
|
- `featuresLifecycle.py` und `workflow` nach `gateway/modules/workflows/automation/` verschieben.
|
|
- `dynamicOptions` entfernen und UI/API auf Options-Routen umstellen.
|
|
- Referenzen auf `modules/interfaces/interfaceDb*.py` und `modules/datamodels/datamodel*.py` anpassen.
|
|
|
|
### Machbarkeit und Bedenken
|
|
- Shared Interfaces/Models (chatbot/workflow) brauchen klare Ownership oder Shared-Modul.
|
|
- Feature-Lifecycle sollte Feature-Registry dynamisch laden.
|
|
- Feature-Registry (`routeFeatures.py`, `interfaceFeatures.py`, `datamodelFeatures.py`) bleibt global.
|
|
|
|
### Fragen / Klaerungen
|
|
- Bleiben `routeFeatures.py` und `interfaceFeatures.py` global? -> JA
|
|
- Shared chatbot/chat: Shared-Modul oder Duplikation? --> Bereits dupliziert, somit separiert
|
|
- Feature-Discovery dynamisch (scan) oder explizite Imports in `app.py`? -> dynamisch
|
|
|
|
### Propositionen
|
|
- `routeFeatures.py`, `interfaceFeatures.py`, `datamodelFeatures.py` global behalten (System-Feature-Registry).
|
|
- Explizite Imports in `app.py`, aber zentral ueber Feature-Index. --> Die einzelnen Features benötigen keine zentrale komponente mehr. Echt plug & play
|
|
- Event Scheduler + Workflow Engine in `gateway/modules/workflows/automation/` (kein Feature).
|
|
- `dynamicOptions` entfernen, dynamische Daten per spezialisierte API-Routen (RBAC-Admin Stil).
|
|
|
|
### Bedenken
|
|
- Feature-Removal muss Cron/Jobs/Hook-Registrierungen entfernen. --> bereits implementiert. die werden dann nicht mehr gefunden
|
|
- Migration erzeugt viele Import-Aenderungen und Test-Anpassungen. --> korrekt. daher schritt für schritt plan machen
|
|
- `dynamicOptions`-Ablösung erfordert UI/API-Umstellung auf neue Options-Routen.
|
|
|
|
## Services in Feature-Container integrieren
|
|
|
|
### Ziel
|
|
Services, die eindeutig zu Features gehoeren, sollen in den jeweiligen Feature-Container verschoben werden und plug&play geladen werden (analog zu Routes).
|
|
|
|
### Zuordnung
|
|
- **aichat**:
|
|
- `gateway/modules/aicore`
|
|
- `gateway/modules/services/serviceAi`
|
|
- `gateway/modules/services/serviceExtraction`
|
|
- `gateway/modules/services/serviceGeneration`
|
|
- `gateway/modules/services/serviceWeb`
|
|
- **neutralizer**:
|
|
- `gateway/modules/services/serviceNeutralization`
|
|
- **Generisch (bleibt shared):**
|
|
- alle anderen Services bleiben in `gateway/modules/services`
|
|
|
|
### Plug&Play fuer Services (analog Routes)
|
|
- Feature-Container exportiert Service-Registrierung (z.B. `registerServices()`).
|
|
- Zentrale Service-Registry laedt nur vorhandene Feature-Container.
|
|
- Entfernt man den Feature-Ordner, werden auch Services nicht mehr geladen.
|
|
|
|
### Umsetzungsschritte (Ergaenzung)
|
|
|
|
**Schritt S1: aichat-Services verschieben**
|
|
- Move:
|
|
- `gateway/modules/aicore/` -> `gateway/modules/features/aichat/aicore/`
|
|
- Move:
|
|
- `gateway/modules/services/serviceAi/` -> `gateway/modules/features/aichat/services/serviceAi/`
|
|
- `gateway/modules/services/serviceExtraction/` -> `gateway/modules/features/aichat/services/serviceExtraction/`
|
|
- `gateway/modules/services/serviceGeneration/` -> `gateway/modules/features/aichat/services/serviceGeneration/`
|
|
- `gateway/modules/services/serviceWeb/` -> `gateway/modules/features/aichat/services/serviceWeb/`
|
|
- Referenzen anpassen:
|
|
- alle Imports dieser Services auf die neuen Pfade.
|
|
- Service-Registry in aichat registriert diese Module.
|
|
|
|
**Schritt S2: neutralizer-Services verschieben**
|
|
- Move:
|
|
- `gateway/modules/services/serviceNeutralization/` -> `gateway/modules/features/neutralizer/services/serviceNeutralization/`
|
|
- Referenzen anpassen:
|
|
- alle Imports auf neuen Pfad.
|
|
- Service-Registry in neutralizer registriert dieses Modul.
|
|
|
|
**Schritt S3: Service-Discovery**
|
|
- Zentraler Loader (shared) laedt Services pro Feature-Container dynamisch.
|
|
- Shared Services bleiben unveraendert in `gateway/modules/services`.
|
|
|
|
## Umsetzungskonzept (schrittweise)
|
|
|
|
### Schritt 0: Bestandsaufnahme und Freeze
|
|
- **Ziel:** saubere Basis, keine parallelen Feature-Refactors.
|
|
- **Aktion:** Branch erstellen, keine Feature-Folder loeschen vor Abschluss.
|
|
|
|
### Schritt 1: Bootstrap auf System-RBAC reduzieren
|
|
- **Datei:** `gateway/modules/interfaces/interfaceBootstrap.py`
|
|
- **Aenderung:**
|
|
- In `initBootstrap()` entfernen:
|
|
- `initFeatures(db)`
|
|
- `_initFeatureTemplateRoleAccessRules(db)`
|
|
- Entfernen:
|
|
- `_initFeatureTemplateRoles(db)` (Funktion + Call-Sites)
|
|
- `_initFeatureTemplateRoleAccessRules(db)` (Funktion + Call-Sites)
|
|
- **Referenzen:** alle Verweise auf Feature-Template-Rollen und Feature-AccessRules loeschen.
|
|
- **Ergebnis:** Bootstrap erstellt nur System-RBAC bei leerer DB.
|
|
|
|
### Schritt 2: Feature-Container vorbereiten (Ordnerstruktur)
|
|
- **Ziel:** pro Feature ein Container mit klarer Struktur.
|
|
- **Neuer Ordner pro Feature:**
|
|
- `gateway/modules/features/<featureCode>/`
|
|
- Pflicht-Module:
|
|
- `datamodelFeatureXxx.py`
|
|
- `interfaceFeatureXxx.py`
|
|
- `routeFeatureXxx.py`
|
|
- `main<Feature>.py` (registriert UI/RESOURCE Katalog)
|
|
- **Ergebnis:** leere Container fuer `trustee`, `chatbot`, `aichat`, `neutralizer`, `realestate`, `automation`.
|
|
|
|
### Schritt 3: Trustee in Container verschieben
|
|
- **Move:**
|
|
- `gateway/modules/routes/routeFeatureTrustee.py` -> `gateway/modules/features/trustee/routeFeatureTrustee.py`
|
|
- `gateway/modules/interfaces/interfaceDbTrustee.py` -> `gateway/modules/features/trustee/interfaceFeatureTrustee.py`
|
|
- `gateway/modules/datamodels/datamodelTrustee.py` -> `gateway/modules/features/trustee/datamodelFeatureTrustee.py`
|
|
- **Neu:**
|
|
- `gateway/modules/features/trustee/mainTrustee.py` (RBAC UI/RESOURCE Katalogregistrierung)
|
|
- **Referenzen anpassen:**
|
|
- Alle Imports von `routeFeatureTrustee.py`, `interfaceDbTrustee.py`, `datamodelTrustee.py`
|
|
- `app.py` Router-Import und Registrierung
|
|
- Tests, falls vorhanden
|
|
|
|
### Schritt 4: Chatbot in Container verschieben
|
|
- **Move:**
|
|
- `gateway/modules/routes/routeFeatureChatbot.py` -> `gateway/modules/features/chatbot/routeFeatureChatbot.py`
|
|
- `gateway/modules/interfaces/interfaceDbChatbot.py` -> `gateway/modules/features/chatbot/interfaceFeatureChatbot.py`
|
|
- `gateway/modules/datamodels/datamodelChatbot.py` -> `gateway/modules/features/chatbot/datamodelFeatureChatbot.py`
|
|
- **Keep:**
|
|
- `gateway/modules/features/chatbot/mainChatbot.py` + Helpers
|
|
- **Neu:**
|
|
- `gateway/modules/features/chatbot/mainChatbotCatalog.py` (oder in `mainChatbot.py`)
|
|
- **Referenzen anpassen:**
|
|
- Alle Imports von `routeFeatureChatbot.py`, `interfaceDbChatbot.py`, `datamodelChatbot.py`
|
|
- `app.py` Router-Import und Registrierung
|
|
|
|
### Schritt 5: AIChat (chatworkflow) in Container verschieben
|
|
- **Move:**
|
|
- `gateway/modules/routes/routeFeatureChatDynamic.py` -> `gateway/modules/features/aichat/routeFeatureAiChat.py`
|
|
- `gateway/modules/interfaces/interfaceDbChat.py` -> `gateway/modules/features/aichat/interfaceFeatureAiChat.py`
|
|
- `gateway/modules/datamodels/datamodelChat.py` -> `gateway/modules/features/aichat/datamodelFeatureAiChat.py`
|
|
- **Keep:**
|
|
- `gateway/modules/features/workflow/mainWorkflow.py` (falls nur Workflow-Logik)
|
|
- **Neu:**
|
|
- `gateway/modules/features/aichat/mainAiChat.py` (RBAC UI/RESOURCE Katalog)
|
|
- **Referenzen anpassen:**
|
|
- Alle Imports von `routeFeatureChatDynamic.py`, `interfaceDbChat.py`, `datamodelChat.py`
|
|
- `app.py` Router-Import und Registrierung
|
|
|
|
### Schritt 6: Neutralizer in Container verschieben und Ordner umbenennen
|
|
- **Rename:**
|
|
- `gateway/modules/features/neutralizePlayground/` -> `gateway/modules/features/neutralizer/`
|
|
- **Move:**
|
|
- `gateway/modules/routes/routeFeatureNeutralization.py` -> `gateway/modules/features/neutralizer/routeFeatureNeutralizer.py`
|
|
- `gateway/modules/datamodels/datamodelNeutralizer.py` -> `gateway/modules/features/neutralizer/datamodelFeatureNeutralizer.py`
|
|
- **Neu:**
|
|
- `gateway/modules/features/neutralizer/mainNeutralizer.py` (RBAC UI/RESOURCE Katalog)
|
|
- **Referenzen anpassen:**
|
|
- Alle Imports auf `neutralizePlayground`
|
|
- `app.py` Router-Import und Registrierung
|
|
|
|
### Schritt 7: RealEstate in Container verschieben
|
|
- **Move:**
|
|
- `gateway/modules/routes/routeFeatureRealEstate.py` -> `gateway/modules/features/realestate/routeFeatureRealEstate.py`
|
|
- `gateway/modules/interfaces/interfaceDbRealEstate.py` -> `gateway/modules/features/realestate/interfaceFeatureRealEstate.py`
|
|
- `gateway/modules/datamodels/datamodelRealEstate.py` -> `gateway/modules/features/realestate/datamodelFeatureRealEstate.py`
|
|
- **Keep:**
|
|
- `gateway/modules/features/realEstate/mainRealEstate.py`
|
|
- **Neu:**
|
|
- `gateway/modules/features/realestate/mainRealEstateCatalog.py` (oder in mainRealEstate)
|
|
- **Referenzen anpassen:**
|
|
- Alle Imports der alten Pfade
|
|
- `app.py` Router-Import und Registrierung
|
|
|
|
### Schritt 8: Automation als Feature-Container
|
|
- **Move:**
|
|
- `gateway/modules/routes/routeDataAutomation.py` -> `gateway/modules/features/automation/routeFeatureAutomation.py`
|
|
- **Neu:**
|
|
- `gateway/modules/features/automation/interfaceFeatureAutomation.py`
|
|
- `gateway/modules/features/automation/datamodelFeatureAutomation.py` (enthaelt `AutomationDefinition`)
|
|
- `gateway/modules/features/automation/mainAutomation.py` (RBAC UI/RESOURCE Katalog)
|
|
- **Referenzen anpassen:**
|
|
- Alle Imports von `routeDataAutomation.py`
|
|
- `app.py` Router-Import und Registrierung
|
|
|
|
### Schritt 9: App-Routing dynamisch
|
|
- **Datei:** `gateway/app.py`
|
|
- **Aenderung:**
|
|
- Entferne direkte Imports aus `modules/routes/`.
|
|
- Importiere Router aus Feature-Containern dynamisch (Feature-Discovery).
|
|
- **Referenzen:** alle Router-Registrierungen auf neue Pfade/Discovery umstellen.
|
|
|
|
### Schritt 10: featuresLifecycle anpassen
|
|
- **Datei:** `gateway/modules/features/featuresLifecycle.py`
|
|
- **Aenderung:**
|
|
- Feature-Registry dynamisch laden (Folder-Discovery).
|
|
- Keine direkten Imports aus alten Pfaden.
|
|
- **Referenzen:** Aufrufe in `app.py` bleiben, aber Lifecycle nutzt Feature-Liste.
|
|
|
|
### Schritt 11: Referenzen global bereinigen
|
|
- **Ziel:** Import-Pfade konsistent.
|
|
- **Aenderungen:**
|
|
- Alle Imports von `modules/routes/routeFeature*.py` entfernen.
|
|
- Alle Imports von `modules/interfaces/interfaceDb*.py` auf `interfaceFeature*.py` umstellen.
|
|
- Alle Imports von `modules/datamodels/datamodel*.py` auf `datamodelFeature*.py` umstellen.
|
|
|
|
### Schritt 12: RBAC Katalog Registrierungen pro Feature
|
|
- **Ziel:** jede Feature-Instanz registriert UI/RESOURCE Keys.
|
|
- **Dateien:** `main<Feature>.py` je Feature-Container
|
|
- **Aenderung:** einheitliche Registrierungs-API verwenden (im Katalog-Service).
|
|
|
|
### Schritt 13: Tests und Verifikation
|
|
- **Smoke Tests:**
|
|
- Start Gateway, pruefen dass alle Feature-Routes registriert sind.
|
|
- Entferne Feature-Ordner testweise -> Route nicht mehr vorhanden.
|
|
- RBAC Katalog liefert Objekte fuer alle Features.
|
|
- Bootstrap erzeugt nur System-RBAC bei leerer DB.
|