Gefunden bei Fable-Review auf Code-Dopplung/interne Links (Session 2026-10-19), Nachtrag zu PR #368.
Problem: Drei Backend-APIs setzen keinerlei requirePermission-Pruefung durch:
ai/internal/semanticsearchapi (ai-search-chat) -- Permission ai.search.read existiert bereits in migrations/0018_module_policy_rules.up.sql, wird aber nirgends im Handler abgefragt.
workflow/internal/taskapi (workflow-tasks) -- keine passende Permission existiert ueberhaupt, muesste neu angelegt werden (z.B. workflow.task.read).
connect/internal/connectorsetupapi (connect-setup) -- keine passende Permission existiert, muesste neu angelegt werden.
Zum Vergleich: mail/internal/mailapi setzt mail.message.read korrekt durch (mailapi.go:120-121), deshalb konnte fuer mail-postfach in PR #368 ein echter Registry-Eintrag ergaenzt werden -- fuer diese drei Apps waere das aktuell eine vorgetaeuschte Absicherung.
Akzeptanzkriterien (Vorschlag):
Jede der drei APIs prueft die jeweilige Permission serverseitig vor Verarbeitung der Anfrage (gleiches Muster wie s.requirePermission(...) in connect/internal/statusapi/statusapi.go:37).
Fuer workflow-tasks und connect-setup: neue Permission-Keys per Migration anlegen, inkl. Rollenzuordnung (user/tenant_admin), analog migrations/0018_module_policy_rules.up.sql.
Je Akzeptanzkriterium ein automatisierter Test (401/403 ohne/mit falscher Rolle).
Danach: MODULE_REGISTRY in web/shl/components/ModuleNavShell.tsx um die drei Apps ergaenzen (analog mail_postfach in PR #368), Navigation einbinden.
Nicht Bestandteil: Entscheidung, ob ai-search-chat/workflow-tasks oder ihre Schwester-Apps (ai-summaries/workflow-approvals) langfristig die kanonische App je Bereich bleiben -- reine Produktentscheidung, hier nur die fehlende Absicherung.
Gefunden bei Fable-Review auf Code-Dopplung/interne Links (Session 2026-10-19), Nachtrag zu PR #368.
**Problem:** Drei Backend-APIs setzen keinerlei `requirePermission`-Pruefung durch:
- `ai/internal/semanticsearchapi` (ai-search-chat) -- Permission `ai.search.read` existiert bereits in `migrations/0018_module_policy_rules.up.sql`, wird aber nirgends im Handler abgefragt.
- `workflow/internal/taskapi` (workflow-tasks) -- keine passende Permission existiert ueberhaupt, muesste neu angelegt werden (z.B. `workflow.task.read`).
- `connect/internal/connectorsetupapi` (connect-setup) -- keine passende Permission existiert, muesste neu angelegt werden.
Zum Vergleich: `mail/internal/mailapi` setzt `mail.message.read` korrekt durch (`mailapi.go:120-121`), deshalb konnte fuer mail-postfach in PR #368 ein echter Registry-Eintrag ergaenzt werden -- fuer diese drei Apps waere das aktuell eine vorgetaeuschte Absicherung.
**Akzeptanzkriterien (Vorschlag):**
1. Jede der drei APIs prueft die jeweilige Permission serverseitig vor Verarbeitung der Anfrage (gleiches Muster wie `s.requirePermission(...)` in `connect/internal/statusapi/statusapi.go:37`).
2. Fuer workflow-tasks und connect-setup: neue Permission-Keys per Migration anlegen, inkl. Rollenzuordnung (user/tenant_admin), analog `migrations/0018_module_policy_rules.up.sql`.
3. Je Akzeptanzkriterium ein automatisierter Test (401/403 ohne/mit falscher Rolle).
4. Danach: MODULE_REGISTRY in `web/shl/components/ModuleNavShell.tsx` um die drei Apps ergaenzen (analog `mail_postfach` in PR #368), Navigation einbinden.
**Nicht Bestandteil:** Entscheidung, ob ai-search-chat/workflow-tasks oder ihre Schwester-Apps (ai-summaries/workflow-approvals) langfristig die kanonische App je Bereich bleiben -- reine Produktentscheidung, hier nur die fehlende Absicherung.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Gefunden bei Fable-Review auf Code-Dopplung/interne Links (Session 2026-10-19), Nachtrag zu PR #368.
Problem: Drei Backend-APIs setzen keinerlei
requirePermission-Pruefung durch:ai/internal/semanticsearchapi(ai-search-chat) -- Permissionai.search.readexistiert bereits inmigrations/0018_module_policy_rules.up.sql, wird aber nirgends im Handler abgefragt.workflow/internal/taskapi(workflow-tasks) -- keine passende Permission existiert ueberhaupt, muesste neu angelegt werden (z.B.workflow.task.read).connect/internal/connectorsetupapi(connect-setup) -- keine passende Permission existiert, muesste neu angelegt werden.Zum Vergleich:
mail/internal/mailapisetztmail.message.readkorrekt durch (mailapi.go:120-121), deshalb konnte fuer mail-postfach in PR #368 ein echter Registry-Eintrag ergaenzt werden -- fuer diese drei Apps waere das aktuell eine vorgetaeuschte Absicherung.Akzeptanzkriterien (Vorschlag):
s.requirePermission(...)inconnect/internal/statusapi/statusapi.go:37).migrations/0018_module_policy_rules.up.sql.web/shl/components/ModuleNavShell.tsxum die drei Apps ergaenzen (analogmail_postfachin PR #368), Navigation einbinden.Nicht Bestandteil: Entscheidung, ob ai-search-chat/workflow-tasks oder ihre Schwester-Apps (ai-summaries/workflow-approvals) langfristig die kanonische App je Bereich bleiben -- reine Produktentscheidung, hier nur die fehlende Absicherung.