All checks were successful
Deploy Development / deploy (push) Successful in 44s
Test Suite / pytest-backend (push) Successful in 42s
Test Suite / lint-backend (push) Successful in 0s
Test Suite / build-frontend (push) Successful in 13s
Test Suite / k6 /health Baseline (push) Successful in 35s
Test Suite / playwright-tests (push) Successful in 1m51s
- Updated the capability catalog to reflect a registry-first approach, requiring modules to register rights and quotas upon implementation. - Enhanced the backend to synchronize the rights registry with the database, ensuring only registered capabilities and features are displayed in the admin matrix. - Modified SQL queries in the admin rights router to filter capabilities and features based on module registration. - Updated documentation to clarify the new rights and features registry process, replacing the previous catalog-first method. - Incremented application version to 0.8.201 and updated database schema version to 20260606084 to reflect these changes.
3.4 KiB
3.4 KiB
Rechte & Kontingente — Registry-first (Zielarchitektur)
Stand: 2026-06-07 · Status: verbindlich (korrigiert Katalog-first aus Migration 079)
1. Problem mit dem Katalog-first-Ansatz
Migration 079_capabilities.sql hat ~70 Rechte vorab in die DB geschrieben — aus einer Spekulation über die fertige App. Das ist für ein System im Aufbau verkehrt herum:
- Vollständige Liste ist nicht möglich und nicht wünschenswert
- Die Matrix suggeriert Funktionen, die es am Endpoint noch nicht gibt
- Module registrieren sich nicht — alles war manueller Seed
Korrektur: Registry-first — wie bei anderen Registries im Projekt (z. B. Platzhalter-Pflicht).
2. Zielbild
Modul implementiert Feature
→ register_capability() / register_feature() in rights_registrations/<modul>.py
→ Startup: sync_rights_registry_to_db()
→ Admin „Rollen & Rechte“ zeigt nur Einträge mit module IS NOT NULL
→ Endpoint: probe_capability + probe/consume Kontingent
| Achse | Registrierung | Konfiguration Admin |
|---|---|---|
| Recht | CapabilityRegistration |
Matrix Vereins-/Portal-Rollen |
| Kontingent | FeatureRegistration |
Vereinspläne / Limits |
Kein neuer Eintrag in 079-artigen Bulk-Migrations für fachliche Rechte.
3. Implementierung (Code)
| Pfad | Rolle |
|---|---|
backend/rights_registry.py |
register_capability, register_feature, sync_rights_registry_to_db |
backend/rights_registrations/*.py |
Pro Modul nur tatsächlich verdrahtete Rechte/Kontingente |
backend/main.py |
Sync nach Migrationen |
Migration 084_rights_registry_module.sql |
Spalte module auf capabilities + features |
admin_rights.py |
Matrix-Query: WHERE module IS NOT NULL |
Neues Modul anbinden (Pflicht)
- Datei
rights_registrations/mein_modul.pyanlegen register_capability/register_featureaufrufen- In
rights_registrations/__init__.pyimportieren - Endpoint:
probe_capability+ ggf.consume_club_feature_with_usage capability_enforcement_audit.WIRED_PROBEergänzen
Kein Eintrag in CAPABILITY_CATALOG als Voraussetzung für DB — der Katalog wird zur Dokumentation der Namenskonvention, nicht zur Seed-Quelle.
4. Legacy-Katalog (079)
- Bleibt in der DB (
module IS NULL) für Übergang /check_capability-Kompatibilität - Erscheint nicht mehr in der Admin-Matrix
- Wird nicht erweitert — neue Rechte nur über Registry
- Langfristig: ungenutzte Seed-Zeilen deaktivieren oder archivieren
5. Aktuell registrierte Module (Start)
| Modul | Rechte | Kontingente |
|---|---|---|
exercises |
KI suggest/regenerate, create, media.upload | ai_calls, exercises, exercise_media |
planning_exercise_suggest |
planning.ai.* | (nutzt ai_calls) |
club_creation_requests |
Gründung + approve | — |
platform |
admin.access, quota.bypass | — |
Weitere Module folgen mit ihrer Implementierung, nicht vorher.
6. Referenzen
docs/working/RBAC_ENFORCEMENT_ROADMAP.md— Enforcement nach VerdrahtungMEMBERSHIP_RBAC_DECISIONS_2026-06.md— ProduktentscheidungenCLUB_MEMBERSHIP_AND_FEATURES.v1.md— Kontingent-Semantik
Changelog
- 2026-06-07: Registry-first als verbindliche Korrektur; Migration 084; Pilot-Registrierungen.