Files
AfiS-Aktensystem/web/lib/notify/enqueue.ts
T
Harlekin cf4348b8b1 Phase 6 abgeschlossen: Aktenchat, Kanäle, Echtzeit, Benachrichtigungen
Ein Ereignisstrom mit Themen (/api/stream), in dem der Dateistrom aus Phase 5
aufgegangen ist. Zwei Prüfungen: beim Verbinden, welche Themen der Nutzer
abonnieren darf, und je Ereignis wird der Inhalt mit seinen Rechten geladen.
Das zweite ist nicht nur Vorsicht — eine Umklassifizierung wirkt dadurch in
einer offenen Verbindung sofort. In der pg_notify-Nutzlast steht nie ein
Inhalt, nur Thema, Art und Kennung.

Der Aktenchat sendet optimistisch mit clientseitiger UUIDv7, die zugleich
Idempotenzschlüssel ist. Antworten, vier feste Reaktionen, Bearbeiten mit
sichtbarem editedAt, Zurückziehen mit Platzhalter — Löschen gibt es nicht, und
eine Regel in der Datenbank hält das fest. Eine zurückgezogene Nachricht kommt
ohne Text an, nicht ausgeblendet.

Aktenzeichen im Text werden zu Vorschaukarten, serverseitig aufgelöst. Eine
Akte, die der Leser nicht sehen darf, sieht darin genauso aus wie eine, die es
gar nicht gibt.

"Als Vermerk übernehmen" steht sichtbar an jeder Nachricht. Der Vermerk gehört
dem Verfasser, nicht dem Übernehmenden; ein Systemeintrag nennt den Ursprung,
damit der Wortlaut später nicht für die Akte geschrieben wirkt.

Bei den Discord-Benachrichtigungen entscheidet die Web-App, wer was erfährt,
und der Worker liefert nur aus. Die Alternative hätte geheissen, die
Sichtbarkeitsprüfung im Worker ein zweites Mal zu bauen. In meta steht ein
Titel nur, wenn er hinaus darf — ab Stufe 3 keiner. Postausgang als Tabelle,
angestossen über LISTEN, mit Takt als Sicherheitsnetz.

Nebenbei riss das Budget der Fallakte erneut (122 kB). Drei Schritte zurück
auf 119,6: Chattexte in eine eigene i18n-Datei, ein gemeinsames AddPanel statt
viermal derselbe Aufklapp-Code, und eine eigene UUIDv7 statt des Pakets — die
Sortierbarkeit, auf der die Nachlieferung beruht, steht damit im eigenen Code
und hat Tests.

Unterwegs habe ich NotifyMode und User.notifyMode ein zweites Mal angelegt,
obwohl es beides seit dem Grundgerüst gibt. Die Migration schlug fehl und die
Datenbank musste von Hand aufgeräumt werden; die Lehre steht in docs/13.

155 Tests im Web-Paket, 15 in der Datenbank, 7 im Worker, 32 e2e.
2026-09-02 21:06:03 +02:00

125 lines
4.0 KiB
TypeScript

import { db } from '@/lib/db'
import { READ_AUDIT_FROM_LEVEL } from '@/lib/audit'
import { visibleCaseWhere } from '@/lib/access/caseFilter'
import { resolvePermissions } from '@/lib/auth/effective'
import type { Prisma } from '@afis/db'
/**
* Benachrichtigungen in den Postausgang legen.
*
* **Die Web-App entscheidet, wer was erfahren darf; der Worker liefert nur
* aus.** Das ist die wichtigste Trennung hier: die Sichtbarkeitsprüfung steckt
* in dieser Anwendung, und sie im Worker ein zweites Mal zu bauen hiesse, sie
* zweimal richtig haben zu müssen.
*
* Deshalb steht in `meta` nur, was **stehen darf** — fertig entschieden. Ein
* Titel landet dort nur, wenn er auch nach Discord darf. Der Worker setzt
* daraus einen Satz zusammen und hat keine Entscheidung mehr zu treffen.
* Siehe docs/06-chat-und-realtime.md.
*/
/** Ab dieser Stufe geht nicht einmal der Titel nach Discord. */
const TITLE_HIDDEN_FROM = READ_AUDIT_FROM_LEVEL
export type OutboxKind = 'entry.new' | 'chat.new' | 'chat.mention' | 'case.status'
/**
* Die Empfänger einer Meldung zu einer Akte.
*
* Wer die Akte nicht sehen darf, bekommt nichts — auch keinen Hinweis, dass es
* sie gibt. Geprüft wird mit **derselben** Abfrage wie beim Lesen:
* `visibleCaseWhere`, je Empfänger. Das ist eine Abfrage pro Kandidat und bei
* dieser Nutzerzahl billiger als der Fehler, die Regel ein zweites Mal zu
* bauen und eine der beiden Fassungen später zu vergessen.
*/
async function empfaenger(
caseId: string,
actorId: string,
nurDiese?: string[],
): Promise<string[]> {
const [beteiligt, beobachtend, kandidaten] = await Promise.all([
db.caseParticipant.findMany({
where: { caseId, userId: { not: null } },
select: { userId: true },
}),
db.watch.findMany({ where: { caseId }, select: { userId: true } }),
db.user.findMany({
where: {
isActive: true,
notifyMode: { not: 'OFF' },
id: { not: actorId, ...(nurDiese ? { in: nurDiese } : {}) },
},
select: { id: true, notifyMode: true },
}),
])
const nah = new Set(
[...beteiligt.map((b) => b.userId!), ...beobachtend.map((w) => w.userId)].filter(Boolean),
)
const ziele: string[] = []
for (const nutzer of kandidaten) {
// Ausdrücklich gemeint zu sein hebt die Einstellung nicht auf, aber
// "MENTIONS" heisst eben genau: nur dann.
if (nutzer.notifyMode === 'MENTIONS' && nurDiese === undefined) continue
if (nutzer.notifyMode === 'OWN_CASES' && !nah.has(nutzer.id) && nurDiese === undefined) {
continue
}
const rechte = await resolvePermissions(nutzer.id)
const sichtbar = await db.case.findFirst({
where: { AND: [visibleCaseWhere(rechte), { id: caseId }] },
select: { id: true },
})
if (sichtbar) ziele.push(nutzer.id)
}
return ziele
}
/**
* Legt die Zeilen an: eine je Empfänger für die Direktnachricht, plus eine
* ohne Empfänger für den allgemeinen Kanal.
*/
export async function enqueueCaseNotification(
tx: Prisma.TransactionClient,
input: {
kind: OutboxKind
caseId: string
caseNumber: string
classification: number
actorId: string
actorName: string
/** Nur gesetzt, wenn ausdrücklich bestimmte Leute gemeint sind. */
onlyFor?: string[]
meta?: Record<string, unknown>
title?: string
},
): Promise<void> {
// Ab Stufe 3 geht nicht einmal der Titel raus. Discord kennt unsere
// Klassifizierung nicht, der Link führt zur App, die selbst prüft.
const titel = input.classification >= TITLE_HIDDEN_FROM ? null : (input.title ?? null)
const gemeinsam = {
kind: input.kind,
caseId: input.caseId,
actorId: input.actorId,
meta: {
caseNumber: input.caseNumber,
actorName: input.actorName,
title: titel,
...input.meta,
} as Prisma.InputJsonValue,
}
const ziele = await empfaenger(input.caseId, input.actorId, input.onlyFor)
await tx.notificationOutbox.createMany({
data: [
// In den allgemeinen Kanal, ohne Empfänger.
gemeinsam,
...ziele.map((ziel) => ({ ...gemeinsam, recipientId: ziel })),
],
})
}