struct-i-vio
StartseiteDokumentationModuleTeam
Plattform & Einstieg · Projektmodul

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

Projektteam und Besetzungen verwalten. Das Modul wird in der passenden Verwaltungs- oder Arbeitsoberfläche freigeschaltet und genutzt.

  • Team erklärt kompakt, wofür der Bereich gedacht ist und wann er im Arbeitsalltag relevant wird.
  • Der Bereich spielt in der Praxis besonders mit Aufgaben und Dokumente zusammen.
  • Nutzen, Sichtbarkeit und Verantwortlichkeit ergeben sich hier stark aus dem Projektkontext.
Zur ModulübersichtRollen & Berechtigungen lesen
Direkt zu
Modulzweck

Wofür das Modul gedacht ist

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

Projektteam und Besetzungen verwalten. Im Projektkontext bedeutet das, dass der Bereich nicht isoliert funktioniert, sondern direkt an Team, Status und weitere Projektbereiche anknüpft.

Team 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 wird in der passenden Verwaltungs- oder Arbeitsoberfläche freigeschaltet und genutzt.
Praxisbezug

Typische Einsatzfälle

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

Schnell Orientierung gewinnen

Team 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

Aufgaben

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

Details
Projektmodul

Dokumente

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

Details
Projektmodul

Projekt-Infos

Projekt-Infos ergänzt Team, 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.
Das Modul hat keinen eigenständigen Hauptmenüpfad. Zugriff und Aktionen greifen direkt in den jeweiligen Verwaltungs- oder Projektoberflächen.
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

Backbone-Modul. Mehrere andere Module hängen indirekt an project_team.view_team via dim_projects_select_own (project_members EXISTS-Subquery). Eine Verweigerung dieser Permission kappt damit eine Reihe scheinbar unabhängiger Funktionen quer über die Module.

Entwickler-Info aufklappen (4)

⚠ KRITISCHview_team ist Voraussetzung für viele indirekte Cross-Module-Aktionen

dim_projects.select_own enthält EXISTS(SELECT FROM project_members ...). Diese Subquery läuft im RLS-Kontext des aufrufenden Users; project_members_select_project verlangt project_team.view_team. Konsequenz: Ein Member ohne view_team kann seine eigene Mitgliedschaft nicht sehen und das Projekt verschwindet aus UPDATE-RETURNING auf dim_projects (404 statt 200). Bekannte betroffene Aktionen: project_overview.edit_project_address, project_documents.*, project_bautagebuch.*. Diese sind via MANUAL_PERMISSION_DEPENDENCIES schon erfasst.

  • RLS: dim_projects_select_own (EXISTS subquery on project_members)
  • lib/permission-dependencies.ts: cross_module-Regel project_overview.edit_project_address

Pattern: scoped + global, getrennte INSERT/UPDATE/DELETE pro Modus

Statt _all/scoped als OR-Klausel wie in transfers / project_payments hat project_members je eine SEPARATE Policy pro (CMD, scope) — z.B. project_members_insert_project (mit add_member) UND project_members_insert_all (mit manage_team_all). Beide Policies sind PERMISSIVE, Postgres ORt sie automatisch.

  • RLS: 12 Policies auf project_members (3 per CMD × {project, all, superadmin})

⚡ MERKWÜRDIGadd_member regiert auch UPDATE — keine getrennte "Rolle ändern"-Permission

INSERT und UPDATE auf project_members teilen sich beide add_member (project-scoped). Wer Mitglieder hinzufügen kann, kann damit auch automatisch deren Rolle / Position ändern. Eine feiner-granulare Trennung wäre Schema-Erweiterung.

⚡ MERKWÜRDIGmanage_team_all wirkt nur teilweise — API-Auth blockiert vorne

pages/api/projects/[id]/members.ts:102 prüft VOR der RLS-Schicht eigenständig "Nur Management oder Projektleitung können das Team bearbeiten". Wer manage_team_all hat, aber weder Level<=0 noch PL-Status, wird vor dem DB-Layer abgewiesen. Die Permission greift de facto nur in Direkt-DB-Pfaden (Service-Tools, Migrations).

  • pages/api/projects/[id]/members.ts:102
Vorherige Seite

Module

Der öffentliche Modulkatalog von struct-i-vio mit einer eigenen Docs-Seite für jeden aktiven Produktbaustein.

Jetzt loslegen

struct-i-vio im eigenen Setup testen

Wenn Sie den Einstieg konkret planen, können Sie direkt einen eigenen Arbeitsbereich anlegen.