Berechtigungen und Zugriffskontrolle

Überblick

Corcava setzt ein umfassendes rollenbasiertes Zugriffssystem um, das Teammitgliedern angemessenen Zugriff auf Projekte, Bretter und Aufgaben gibt und dabei Sicherheit und Datentrennung wahrt. Laut Code-Analyse nutzt das System eine Kombination aus Benutzerrollen, Berechtigungsprüfung und teambasierter Isolation für den Zugriff auf Projektmanagement-Funktionen.

Das Verständnis des Berechtigungssystems hilft Ihnen, Teamzugriff sinnvoll zu konfigurieren und angemessene Sicherheit für Projekte und Kundendaten zu wahren.

Rollenbasierter Zugriff – Benutzerrollen und Möglichkeiten

Benutzerrollen-System

Verfügbare Rollen: Laut Code-Analyse gibt es 7 Benutzerrollen:

1. SUPERADMIN

Vollzugriff auf das System – Volle Kontrolle über alle Organisationsdaten und -einstellungen
isShowAllAndOwnProjectCRUD() – Kann alle Projekte einsehen und verwalten
isShowAllAndOwnTaskCRUD() – Kann alle Aufgaben einsehen und verwalten
Teamverwaltung – Kann alle Teammitglieder und Rollen verwalten
Finanzkontrolle – Zugriff auf alle Rechnungs- und Finanzfunktionen

2. ORGANIZATION_MANAGER

Teamführung – Teams, Projekte und Organisations-Einstellungen verwalten
isShowAllAndOwnProjectCRUD() – Kann alle Team-Projekte einsehen und verwalten
isShowAllAndOwnTaskCRUD() – Kann alle Team-Aufgaben einsehen und verwalten
Kundenverwaltung – Vollzugriff auf Kundenbeziehungen und -daten
Finanzzugriff – Kann Rechnungen und Ausgaben verwalten

3. SALES_MANAGER

Vertrieb – Vertriebsaktivitäten überwachen und Vertriebsteam führen
isShowAllAndOwnTaskCRUD() – Kann alle Aufgaben einsehen und verwalten
isShowAllAndOwnContactCRUD() – Kann alle Kontakte und Leads verwalten
isShowAllAndOwnDealCRUD() – Kann alle Deals und Opportunities verwalten
Projekterstellung – Kann Projekte für Kunden anlegen
Begrenzter Finanzzugriff – Kann Rechnungen erstellen, Finanzzugriff eingeschränkt

4. SALES_REPRESENTATIVE

Fokussierter Vertriebszugriff – Nur Zugriff auf zugewiesene Leads und Deals
isShowAllAndOwnDealCRUD() – Kann Deals und Opportunities verwalten
Projekterstellung – Kann Projekte für seine Kunden anlegen
Begrenzter Umfang – Kein Zugriff auf Daten anderer Teammitglieder
Kundeninteraktion – Kann zugewiesene Kundenbeziehungen verwalten

5. PROJECT_MANAGER (Veraltet)

Veraltet – Diese globale Rolle wurde entfernt
Stattdessen – is_manager=true in der Pivot-Tabelle project_users für projektbezogenes Management setzen
Projektmanager – Benutzer können über die Projekt-Bearbeitungsseite als Manager bestimmter Projekte festgelegt werden

6. USER

Aufgabenausführung – Kann an zugewiesenen Aufgaben und Projekten arbeiten
Projektzuweisung nötig – Muss Projekten zugewiesen sein für Zugriff
Kollaborationszugriff – Kann kommentieren, Benutzer zuweisen und Zeit erfassen
Begrenzte Administration – Kann keine Projekte anlegen oder Team-Einstellungen verwalten

7. PROJECT_VIEWER

Kundenportal-Rolle – Für Kundenportal-Zugriff vorgesehen
Zwei Untertypen – Varianten „viewer“ und „manager“
Projektzuweisung nötig – Muss bestimmten Projekten zugewiesen sein
Lese-/Schreibzugriff – Kann zugewiesene Projekte einsehen und nutzen
Kostenlose Rolle – Das Hinzufügen von Benutzern in dieser Rolle ist kostenlos

Details zur Rollen-Implementierung

Rollenprüf-Methoden: Laut User-Model-Analyse:

hasRole(RoleName $role) – Prüft, ob der Benutzer eine bestimmte Rolle hat
Rollenspezifische Methoden – isSuperAdmin(), isOrganizationManager() usw.
Berechtigungsprüfung – hasPermission(string $permission)
CRUD-Berechtigungsgruppen – isShowAllAndOwnProjectCRUD() usw.

Untertypen von Project Viewer:

isViewer() – PROJECT_VIEWER mit project_viewer-Wert „viewer“
isViewerManager() – PROJECT_VIEWER mit project_viewer-Wert „manager“
isProjectViewer() – Jede PROJECT_VIEWER-Rolle unabhängig vom Untertyp

Berechtigungen auf Projektebene – Wer auf welche Projekte zugreifen kann

Projekt-Zugriffskontrolle

Umsetzung der Projektberechtigungen: Laut ProjectPolicy-Analyse:

Projekte anzeigen (viewAny):

Berechtigungsprüfung – Benutzer mit Berechtigung „project.viewAny“
Betrachterzugriff – Projektbetrachter können zugewiesene Projekte sehen
Team-Isolation – Benutzer sehen nur Projekte ihres Teams

Projekte erstellen (create):

Admin-Rollen – isShowAllAndOwnProjectCRUD() (Superadmin, OrgManager)
Vertriebsrollen – Vertriebsmanager und Vertriebsmitarbeiter können Projekte anlegen
Einschränkung für User – Normale Benutzer können keine Projekte anlegen

Projekte bearbeiten (edit/update):

Berechtigungsbasiert – Benutzer mit Berechtigung „project.update“
Betrachter-Ausnahme – Projektbetrachter können bearbeiten, wenn dem Projekt zugewiesen
Inhaberbasiert – Vertriebsbenutzer können ihre eigenen Projekte bearbeiten
Team-Validierung – Alle Bearbeitungen erfordern dieselbe Teamzugehörigkeit

Projekt löschen/archivieren:

Admin-Kontrolle – Vor allem Admin- und Manager-Rollen
Inhaberrechte – Vertriebsbenutzer können ihre eigenen Projekte löschen
Team-Isolation – Löschen nur innerhalb desselben Teams möglich

Projekt-Zuweisungssystem

Projekt-Benutzer-Beziehungen:

Benutzerzuweisungssystem – Explizite Zuweisung von Benutzern zu Projekten
belongsToProject() – Methode zur Prüfung, ob Benutzer zu einem Projekt gehört
Team-Validierung – Projektzuweisung erfordert dieselbe Teamzugehörigkeit
Berechtigungs-Kaskade – Projektzuweisung beeinflusst Brett- und Aufgaben-Zugriff

Vorteile der Zuweisung: ✅ Granulare Kontrolle – Bestimmte Benutzer bestimmten Projekten zuweisen
✅ Sicherheits-Isolation – Benutzer greifen nur auf zugewiesene Projekte zu
✅ Flexible Verwaltung – Benutzer einfach zu Projekten hinzufügen/entfernen
✅ Berechtigungsvererbung – Projektzuweisung ermöglicht Brett- und Aufgaben-Zugriff

Brett-Sicherheit – Brettspezifische Zugriffskontrollen

Brett-Berechtigungssystem

Brett-Zugriffskontrolle: Laut ProjectBoardPolicy-Analyse:

Bretter anzeigen:

Abhängigkeit von Aufgabenberechtigung – Erfordert Berechtigung „task.viewAny“
Projektzuweisung – Muss dem Projekt zugewiesen sein, das das Brett enthält
Teamzugehörigkeit – Muss Mitglied desselben Teams wie das Brett sein
Rollenbasierter Zugriff – Unterschiedliche Zugriffsebenen je nach Benutzerrolle

Bretter erstellen:

Admin-Rollen – Benutzer mit isShowAllAndOwnTaskCRUD() können Bretter erstellen
Normale Benutzer – Können Bretter in zugewiesenen Projekten erstellen
Viewer Manager – Können Bretter in zugewiesenen Projekten erstellen
Einschränkung für Betrachter – Normale Betrachter können keine Bretter erstellen

Brettverwaltung:

Update-Berechtigung – Erfordert Berechtigung „task.update“
Inhaberbasiert – Benutzer können Bretter verwalten, die sie besitzen
Admin-Override – Admins können alle Team-Bretter verwalten
Team-Validierung – Alle Aktionen erfordern dieselbe Teamzugehörigkeit

Brett-Sicherheitsfunktionen

Zugriffsvalidierung:

Mehrstufige Prüfung – Berechtigung, Rolle, Team und Projektzuweisung
Projekt-Benutzer-Join – Komplexe Abfrage mit Verknüpfung von projects und project_users
Team-Isolation – Brettzugriff strikt auf Teammitglieder beschränkt
Berechtigungs-Kaskade – Brettzugriff ermöglicht Spalten- und Aufgaben-Zugriff

Sicherheitsvorteile: ✅ Projektbasierte Sicherheit – Brettzugriff an Projektzuweisung geknüpft
✅ Team-Isolation – Klare Trennung zwischen Teams
✅ Rollenbeachtung – Unterschiedliche Möglichkeiten je nach Rolle
✅ Inhabererkennung – Brettinhaber haben erweiterte Berechtigungen

Berechtigungen auf Aufgabennebene – Feingranularer Aufgaben-Zugriff

Aufgaben-Berechtigungssystem

Aufgaben-Zugriffskontrolle: Laut TaskPolicy-Analyse:

Aufgaben anzeigen:

Team-Validierung – Muss Mitglied desselben Teams wie die Aufgabe sein
Spalten-Team-Prüfung – Prüft, ob Benutzerteam zum Team der Aufgaben-Spalte passt
Alle Rollen erlaubt – Alle Rollentypen können Aufgaben anzeigen (mit Team-Validierung)
Universeller Zugriff – viewAny() gibt true zurück (mit weiteren Validierungen)

Aufgaben erstellen:

Breiter Zugriff – Die meisten Rollen können Aufgaben erstellen (Admin, User, Viewer, Viewer Manager)
Projektzuweisung – Muss Zugriff auf das Zielprojekt haben
Berechtigungsprüfung – Einige Rollen benötigen die Berechtigung „task.update“
Team-Validierung – Aufgabenerstellung auf Teammitglieder beschränkt

Aufgabenverwaltung:

Aufgaben aktualisieren – Ähnliche Berechtigungen wie bei der Erstellung
Aufgaben löschen – Erfordert passende Rolle und Teamzugehörigkeit
Benutzer zuweisen – Kann mit entsprechenden Berechtigungen Benutzer zuweisen
Kommentare hinzufügen – Breiter Zugriff für Team-Kollaboration

Spezielle Aufgabenberechtigungen:

moveToBoard – Kann Aufgaben zwischen Brettern innerhalb desselben Teams verschieben
Zeiterfassung – Projektbetrachter vom Typ „viewer“ können keine Zeit erfassen
Dateizugriff – Zugriff auf Aufgabenanhänge folgt den Aufgabenberechtigungen

Umsetzung der Aufgaben-Sicherheit

Berechtigungsvalidierungs-Muster: Alle Aufgaben-Operationen folgen einem ähnlichen Validierungsmuster:

Team-Validierung – Prüfen, ob Benutzerteam zum Team der Aufgaben-Spalte passt
Rollenprüfung – Prüfen, ob die Rolle die nötigen Berechtigungen hat
Projektzuweisung – Bei Betrachtern prüfen, ob der Benutzer dem Projekt zugewiesen ist
Berechtigungs-String – Wo nötig spezifische Berechtigungs-Strings prüfen

Vorteile der Aufgaben-Sicherheit: ✅ Team-Isolation – Aufgaben zwischen Teams getrennt
✅ Projektbasierter Zugriff – Aufgaben-Zugriff an Projektzuweisung geknüpft
✅ Rollenangemessene Berechtigungen – Unterschiedliche Möglichkeiten je nach Rolle
✅ Feingranulare Kontrolle – Spezifische Berechtigungen für verschiedene Aufgaben-Operationen

Kundenportal-Zugriff – Was Kunden sehen und tun können

Kundenportal-Implementierung

Kundenbenutzer-System: Laut Code-Analyse nutzt der Kundenportal-Zugriff die Rolle PROJECT_VIEWER:

Kundenportal-Funktionen:

DashboardClient-Ansicht – Eigenes Dashboard für Kundenbenutzer
isViewer()-Erkennung – System erkennt Kundenbenutzer und leitet zur Kunden-Oberfläche
Chat-Integration – Automatische Chat-Erstellung für Kundenkommunikation
Widget-Integration – Kundenportal-Widget für Kommunikation

Kunden-Zugriffsberechtigungen:

Projektzuweisung nötig – Kunden müssen bestimmten Projekten zugewiesen sein
Team-Validierung – Kundenzugriff auf ihren Team-Kontext beschränkt
Begrenzter Umfang – Kunden sehen nur zugewiesene Projekte und zugehörige Daten
Professionelle Oberfläche – Eigene kundenorientierte Oberfläche

Kundenportal-Sicherheit

Zugriffskontrolle für Kunden:

Rollenbasierte Weiterleitung – isViewer()-Benutzer werden automatisch zum Kundenportal weitergeleitet
Projekt-Isolation – Kunden sehen nur Projekte, denen sie zugewiesen sind
Datenfilterung – Alle Abfragen nach Kundenzuweisung und Berechtigungen gefiltert
Team-Grenze – Kundenzugriff strikt auf ihr Team beschränkt

Vorteile des Kundenportals: ✅ Sicherer Zugriff – Kunden sehen nur relevante Projektinformationen
✅ Professionelle Oberfläche – Klare, kundenangemessene Oberfläche
✅ Projekttransparenz – Kunden können Projektfortschritt und Status sehen
✅ Kontrollierte Kommunikation – Gesteuerte Kommunikationskanäle mit dem Team

Architektur des Berechtigungssystems

Technische Umsetzung

Berechtigungsspeicherung:

Rollensystem – Speichert verfügbare Benutzerrollen und Möglichkeiten
Benutzer-Rollen-Zuweisung – Verknüpft Benutzer mit Rollen im Team-Kontext
Individuelle Berechtigungen – Spezifische Berechtigungen pro Rolle
Team-Isolation – Alle Berechtigungen auf Team-Ebene begrenzt

Berechtigungsprüfung:

hasPermission() – String-basierte Berechtigungsprüfung
Rollen-Methoden – Spezifische Rollenprüf-Methoden
Policy-Klassen – Eigene Policy-Klassen pro Model
Gate-Registrierung – Automatische Gate-Registrierung für alle Berechtigungen

Sicherheitsebenen:

Authentifizierung – Benutzer muss angemeldet sein
Teamzugehörigkeit – Benutzer muss dem relevanten Team angehören
Rollen-Validierung – Benutzer muss die passende Rolle haben
Berechtigungsprüfung – Benutzer muss die konkrete Berechtigung haben
Projektzuweisung – Benutzer muss dem Projekt zugewiesen sein (wo zutreffend)

Vorteile des Berechtigungssystems

✅ Mehrstufige Sicherheit – Mehrere Validierungsebenen verhindern unbefugten Zugriff
✅ Team-Isolation – Klare Trennung zwischen Teams
✅ Rollenangemessener Zugriff – Berechtigungen entsprechen den Verantwortlichkeiten
✅ Projektspezifische Kontrolle – Feingranulare Kontrolle des Projektzugriffs
✅ Kundensicherheit – Sichere, kontrollierte Nutzung für Kundenbenutzer

Einstieg in die Berechtigungsverwaltung

Kurzanleitung

Schritt 1: Ihre Rolle verstehen

Ihre Benutzerrolle und Berechtigungen prüfen
Verstehen, welche Aktionen Sie ausführen können
Wissen, auf welche Projekte und Daten Sie zugreifen können
Einschränkungen Ihres Zugriffs kennen

Schritt 2: Team-Berechtigungen verwalten

Rollen und Zugriffsebenen der Teammitglieder prüfen
Benutzer den passenden Projekten zuweisen
Sicherstellen, dass Teammitglieder die nötigen Berechtigungen haben
Rollen bei Bedarf an Projektanforderungen anpassen

Schritt 3: Kundenzugriff konfigurieren

Kundenbenutzer mit Rolle PROJECT_VIEWER anlegen
Kunden bestimmten Projekten zuweisen
Kundenportal-Zugriff angemessen konfigurieren
Kundenzugriff testen, um korrekte Isolation zu prüfen

Best Practices für Berechtigungen

✅ Prinzip der minimalen Rechte – Nur den nötigen Zugriff gewähren
✅ Regelmäßige Prüfung – Rollen und Berechtigungen periodisch prüfen
✅ Klare Rollendefinition – Sicherstellen, dass das Team die Zugriffsebenen kennt
✅ Projektzuweisung – Benutzer den relevanten Projekten korrekt zuweisen
✅ Kundentrennung – Kundenzugriff sicher und angemessen halten
✅ Team-Isolation – Klare Grenzen zwischen Teams wahren

Berechtigungsprobleme beheben

Häufige Probleme

Kein Zugriff auf Projekte:

Rolle prüfen – Ob Sie die passende Rolle für Projektzugriff haben
Projektzuweisung – Ob Sie dem konkreten Projekt zugewiesen sind
Teamzugehörigkeit – Ob Sie dem richtigen Team angehören
Berechtigungs-Strings – Ob Sie die erforderlichen Berechtigungs-Strings haben

Aufgaben können nicht erstellt/bearbeitet werden:

Aufgabenberechtigung – Ob Sie die Berechtigung „task.update“ haben
Projektzuweisung – Ob Sie dem Projekt zugewiesen sind
Team-Validierung – Ob Ihr Team zum Team der Aufgabe passt
Rollen-Einschränkungen – Einige Rollen haben eingeschränkten Aufgaben-Zugriff

Kundenportal-Probleme:

Rollenkonfiguration – Ob der Kunde die Rolle PROJECT_VIEWER hat
Projektzuweisung – Ob der Kunde bestimmten Projekten zugewiesen ist
Portal-Einrichtung – Konfiguration des Kundenportal-Widgets prüfen
Team-Kontext – Ob der Kunde im richtigen Team-Kontext ist

Berechtigungs-Debugging

Ihre Berechtigungen prüfen:

Rollenbestätigung – Ihre zugewiesene Rolle bestätigen
Berechtigungsliste – Ihre konkreten Berechtigungen prüfen
Projektzuweisung – Prüfen, welchen Projekten Sie zugewiesen sind
Team-Kontext – Prüfen, ob Sie im richtigen Team sind
Policy-Validierung – Verstehen, welche Policy-Regeln für Ihre Aktionen gelten

Nächste Schritte

Nachdem Sie Berechtigungen und Zugriffskontrolle verstanden haben, können Sie sich mit Folgendem vertiefen:

Mobile und responsive Funktionen – Mobile Oberfläche und Touch-Interaktionen
Berichte und Analysen – Projektperformance und Team-Produktivitätsmetriken
Best Practices und Workflows – Empfohlene Projektmanagement-Ansätze

Merken Sie sich: Das Berechtigungssystem in Corcava soll Sicherheit mit Kollaboration verbinden. Ihre Rolle und Berechtigungen zu kennen hilft Ihnen, effektiv im System zu arbeiten und dabei angemessene Zugriffskontrollen für Team und Kunden zu wahren.