StartseiteDokumentationModuleProjektbeteiligte

Plattform & Einstieg · Projektmodul

Projektbeteiligte: wofür der Bereich im Projektkontext gedacht ist.

Beteiligten-Liste je Projekt (Personen, Rollen, Hauptansprechpartner). Verbindet Kontakte mit Projekten via project_contact_links. Das Modul erscheint innerhalb eines einzelnen Projekts und wirkt damit unmittelbar im Projektkontext.

Projektbeteiligte erklärt kompakt, wofür der Bereich gedacht ist und wann er im Arbeitsalltag relevant wird.
Der Bereich spielt in der Praxis besonders mit Übersicht und Team zusammen.
Nutzen, Sichtbarkeit und Verantwortlichkeit ergeben sich hier stark aus dem Projektkontext.

Zur Modulübersicht Rollen & Berechtigungen lesen

Direkt zu

Modulzweck

Wofür das Modul gedacht ist

Projektbeteiligte ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.

Beteiligten-Liste je Projekt (Personen, Rollen, Hauptansprechpartner). Verbindet Kontakte mit Projekten via project_contact_links. Im Projektkontext bedeutet das, dass der Bereich nicht isoliert funktioniert, sondern direkt an Team, Status und weitere Projektbereiche anknüpft.

Projektbeteiligte ist als eigenständiger Produktbaustein gedacht. Gerade deshalb lohnt sich ein Blick darauf, wie der Bereich mit Rollen, Datenkontext und angrenzenden Modulen zusammenspielt.

Das Modul erscheint innerhalb eines einzelnen Projekts und wirkt damit unmittelbar im Projektkontext.

Praxisbezug

Typische Einsatzfälle

Diese Situationen zeigen, wann der Bereich in einem sauberen Rollout oder im laufenden Betrieb konkret Mehrwert liefert.

Schnell Orientierung gewinnen

Projektbeteiligte bietet einen klaren Einstieg in den jeweiligen Arbeitsbereich.

Mit dem restlichen Produkt verzahnen

Der Bereich arbeitet am besten, wenn Verantwortlichkeiten, Sichtbarkeit und angrenzende Module gemeinsam gedacht werden.

Rollout schrittweise aufbauen

Im Rollout sollte zuerst der relevante Kernnutzen sichtbar sein und später gezielt erweitert werden.

Modulverbindungen

Wie das Modul mit anderen Bereichen zusammenspielt

struct-i-vio ist als zusammenhängende Plattform gedacht. Diese Module liegen fachlich am nächsten bei diesem Bereich.

Projektmodul

Übersicht

Übersicht ergänzt Projektbeteiligte, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.

Details

Projektmodul

Team

Team ergänzt Projektbeteiligte, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.

Details

Sichtbarkeit

Berechtigungen und Sichtbarkeit

Die öffentliche Dokumentation beschreibt die Logik auf Produktniveau - nicht als technische Policy-Liste, sondern als Rollout-Leitfaden.

Die Sichtbarkeit orientiert sich in der Regel am Projektkontext, an Projektmitgliedschaft und an projektbezogenen Zusatzrollen.

Gerade bei Teamarbeit lohnt sich ein abgestuftes Modell aus Sichtbarkeit, Bearbeitung und Freigaben statt einer pauschalen Alles-oder-Nichts-Freigabe.

Empfohlener Einsatz

Best Practices

So bleibt der Bereich bei Einführung und Nutzung anschlussfähig an den restlichen Produktfluss.

Mit einem klaren Kernnutzen starten und nur die angrenzenden Bereiche freischalten, die den Alltag direkt entlasten.

Das Modul mit Rollen, Projektkontext und Navigation so verzahnen, dass Nutzer ohne Zusatzschulungen zurechtfinden.

Im Rollout regelmäßig prüfen, ob der Bereich wirklich für die richtigen Nutzer sichtbar und erreichbar ist.

Tiefer einsteigen

Entwickler Info

Klein (4 Actions = 2 _all/scoped-Paare für view + manage). Im API-Layer existieren ZWEI Cross-Modul-Backdoors als OR-Klauseln: project_bautagebuch.view_bautagebuch öffnet den Sicht-Pfad, admin_projects.edit_project öffnet den Manage-Pfad. Wer eines davon hat, sieht/verwaltet die Beteiligtenliste auch ohne project_participants.* zu besitzen.

Entwickler-Info aufklappen (4)

⚠ KRITISCHCross-Modul-Backdoor: Bautagebuch öffnet die View

In pages/api/projects/[id]/participants.ts:62-79 ist canViewParticipants() als OR-Klausel implementiert: view_project_participants OR view_project_participants_all OR project_bautagebuch.view_bautagebuch. Wer Bautagebuch-View hat, sieht auch die Beteiligten-Liste — auch wenn er project_participants.view_project_participants gar nicht besitzt. Ein Schließen dieser Permission allein reicht nicht: project_bautagebuch.view_bautagebuch muss separat geprüft werden.

pages/api/projects/[id]/participants.ts:62-79

⚠ KRITISCHCross-Modul-Backdoor: admin_projects.edit_project öffnet Manage

In pages/api/projects/[id]/participants.ts:88-103 und [linkId].ts:53-68 ist canManageParticipants() ebenfalls eine OR-Klausel: manage_project_participants OR manage_project_participants_all OR admin_projects.edit_project. Wer Projekt-Stammdaten bearbeiten darf, kann automatisch auch die Beteiligten-Liste verwalten — Hinzufügen, Entfernen, Hauptkontakt setzen — ohne explizite manage_project_participants-Permission.

pages/api/projects/[id]/participants.ts:88-103
pages/api/projects/[id]/participants/[linkId].ts:53-68

POST braucht zusätzlich contacts.view_contacts

Beim Anlegen eines neuen Beteiligten (POST) wird VOR dem Manage-Check geprüft, ob der User contacts.view_contacts hat. Ohne diese Permission liefert der Endpoint 403 "Keine Berechtigung zum Ansehen von Kontakten" — auch wenn die Manage-Permission gesetzt ist. Beim Bearbeiten/Löschen via [linkId] ist dieser Pre-Check NICHT vorhanden.

pages/api/projects/[id]/participants.ts:157-167

Project-Scope-Visibility: Mitgliedschaft oder view_all_projects

Der Endpoint joint dim_projects (loadProject). Ohne projects.view_all_projects oder Projekt-Mitgliedschaft (project_members) bricht die Abfrage mit 404 ab — bevor der Permission-Check überhaupt greift. Bereits in MANUAL_PERMISSION_DEPENDENCIES erfasst.

lib/permission-dependencies.ts: project_participants.view_project_participants → projects.view_all_projects