Wofür das Modul gedacht ist
Aufgaben ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Projektaufgaben mit Status-Tracking und Verantwortlichkeiten. Im Projektkontext bedeutet das, dass der Bereich nicht isoliert funktioniert, sondern direkt an Team, Status und weitere Projektbereiche anknüpft.
Aufgaben ist als eigenständiger Produktbaustein gedacht. Gerade deshalb lohnt sich ein Blick darauf, wie der Bereich mit Rollen, Datenkontext und angrenzenden Modulen zusammenspielt.
Typische Einsatzfälle
Diese Situationen zeigen, wann der Bereich in einem sauberen Rollout oder im laufenden Betrieb konkret Mehrwert liefert.
Projektarbeit koordinieren
Aufgaben unterstützt dabei, operative Arbeit, Termine oder Dokumentation im Projekt zusammenzuführen.
Abstimmung im Team entlasten
Wenn Aufgaben, Informationen und Kontext an einem Ort liegen, werden Abstimmungen schneller und verbindlicher.
Fortschritt sichtbar machen
Projektmodule helfen dabei, Statusveränderungen nachvollziehbar zu halten statt nur reaktiv zu reagieren.
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.
Meine Aufgaben
Meine Aufgaben ergänzt Aufgaben, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsTerminplan
Terminplan ergänzt Aufgaben, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsTeam
Team ergänzt Aufgaben, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsBerechtigungen und Sichtbarkeit
Die öffentliche Dokumentation beschreibt die Logik auf Produktniveau - nicht als technische Policy-Liste, sondern als Rollout-Leitfaden.
Best Practices
So bleibt der Bereich bei Einführung und Nutzung anschlussfähig an den restlichen Produktfluss.
Entwickler Info
Sehr saubere RLS-only-Verdrahtung: Alle 9 Actions (view, create, edit, delete jeweils _project und _all + edit_own_tasks) gates ausschließlich Postgres-RLS auf 6 Tabellen (tasks, task_assignees, task_attachments, task_comments, task_history, task_links). KEIN API-Pre-Check in /api/tasks oder /api/tasks/[id] — die Endpoints vertrauen RLS vollständig.
Entwickler-Info aufklappen (5)
⚠ KRITISCHedit_own_tasks ist irreführend benannt
Der Name suggeriert "eigene Aufgabe bearbeiten", aber die RLS-Policy tasks_update_own nutzt KEIN can_perform_action — sie prüft nur task_assignees-Mitgliedschaft. Wer Assignee einer Task ist, kann sie editieren — egal ob edit_own_tasks gesetzt ist oder nicht. edit_own_tasks gates ausschließlich task_attachments_insert_own (Anhang zur eigenen Task hochladen). Effektiver Action-Name wäre upload_attachment_to_own_task. Beim Schließen dieser Permission wird also nur das Anhang-Hochladen eigener Tasks blockiert — nicht das Editieren der Task selbst.
supabase/migrations/20251210234001_squash_baseline.sql:25623 (task_attachments_insert_own — gates edit_own_tasks)supabase/migrations/20251210234001_squash_baseline.sql:25879 (tasks_update_own — KEIN Permission-Check, nur Mitgliedschaft)
⚠ KRITISCHView impliziert Kommentieren
task_comments_insert_all und task_comments_insert_project gates view_tasks_all/view_project_tasks — nicht eine separate Comment-Permission. Wer Aufgaben sehen darf, kann sie automatisch kommentieren. Analog für task_history_insert_*. Das ist eine bewusste Design-Entscheidung — Kommentieren ist Teil des Lese-Workflows. Wer Kommentare verbieten möchte, müsste view-Permission entziehen.
supabase/migrations/20251210234001_squash_baseline.sql:25680, 25684, 25727, 25731
Reine RLS-Verdrahtung — kein klarer 403
Da die API keinen can_perform_action-Pre-Check macht, sehen User ohne Permission PostgREST-42501-Antworten beim INSERT/UPDATE/DELETE. Das ist semantisch ein 403, aber die Fehler-Message kommt aus dem DB-Layer, nicht aus dem expliziten "Keine Berechtigung"-String der API. Bei UI-Tests entsprechend prüfen.
File-Lifecycle-Couplings
lib/taskFileLifecycle.ts nutzt edit_project_tasks/_all für Restore-Operationen auf gelöschten Task-Anhängen (canRestoreTaskAttachment) und delete_project_tasks/_all für canDeleteTaskComment (fremde Kommentare löschen). Wer edit_project_tasks hat, kann auch Anhänge wiederherstellen; wer delete_project_tasks hat, kann auch fremde Kommentare löschen.
lib/taskFileLifecycle.ts:439-446 (Restore-Coupling)lib/taskFileLifecycle.ts:481-487 (Comment-Delete-Coupling)
AI-Tool-Coupling
project_tasks ist im moduleKeys-Set für ResolvedAIToolContext (toolContext.ts:935). Der AI-Assistant kann Aufgaben lesen, wenn die Modul-Visibility offen ist. Schreib-Operationen via AI-Tool-Calls gehen über standard RPCs und sind RLS-gegated wie normale User-Aktionen.
lib/ai/toolContext.ts:935