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. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Harlekin
co-authored by
Claude Opus 5
Claude Opus 5
parent
5f58d9b96f
commit
34a8b96dd3
@@ -0,0 +1,81 @@
|
||||
-- Phase 6: Chat und Echtzeit.
|
||||
|
||||
-- ===========================================================================
|
||||
-- 1. Erwähnungen an der Nachricht
|
||||
--
|
||||
-- Beim Senden aufgelöst und gespeichert, nicht beim Lesen aus dem Text
|
||||
-- geparst: der Worker braucht sie für die Benachrichtigungen, und er soll
|
||||
-- den Text gar nicht erst sehen.
|
||||
-- ===========================================================================
|
||||
|
||||
ALTER TABLE "ChatMessage"
|
||||
ADD COLUMN "mentions" TEXT[] NOT NULL DEFAULT ARRAY[]::TEXT[];
|
||||
|
||||
CREATE INDEX "ChatMessage_mentions_idx" ON "ChatMessage" USING GIN ("mentions");
|
||||
|
||||
-- ===========================================================================
|
||||
-- 2. Chatnachrichten sind zurückziehbar, nicht löschbar
|
||||
--
|
||||
-- Dieselbe Zusicherung wie beim Verlaufseintrag, eine Stufe schwächer: der
|
||||
-- Chat ist ausdrücklich kein Aktenbestandteil, aber eine Nachricht, auf die
|
||||
-- jemand geantwortet hat, darf nicht spurlos verschwinden.
|
||||
-- ===========================================================================
|
||||
|
||||
CREATE RULE chat_no_delete AS ON DELETE TO "ChatMessage" DO INSTEAD NOTHING;
|
||||
|
||||
-- Autor, Zeitpunkt und Ort einer Nachricht sind unveränderlich. Wer etwas
|
||||
-- anderes sagen will, zieht zurück und schreibt neu.
|
||||
CREATE OR REPLACE FUNCTION chat_immutable_guard() RETURNS trigger AS $$
|
||||
BEGIN
|
||||
IF NEW."authorId" IS DISTINCT FROM OLD."authorId"
|
||||
OR NEW."createdAt" IS DISTINCT FROM OLD."createdAt"
|
||||
OR NEW."caseId" IS DISTINCT FROM OLD."caseId"
|
||||
OR NEW."channelId" IS DISTINCT FROM OLD."channelId" THEN
|
||||
RAISE EXCEPTION 'authorId, createdAt und der Ort einer ChatMessage sind unveränderlich';
|
||||
END IF;
|
||||
RETURN NEW;
|
||||
END;
|
||||
$$ LANGUAGE plpgsql;
|
||||
|
||||
CREATE TRIGGER chat_immutable_guard_trg
|
||||
BEFORE UPDATE ON "ChatMessage"
|
||||
FOR EACH ROW EXECUTE FUNCTION chat_immutable_guard();
|
||||
|
||||
-- ===========================================================================
|
||||
-- 3. Benachrichtigungen
|
||||
-- ===========================================================================
|
||||
|
||||
-- NotifyMode und User.notifyMode gibt es seit dem Grundgeruest, sie werden hier
|
||||
-- nur benutzt. Siehe docs/06-chat-und-realtime.md.
|
||||
|
||||
CREATE TABLE "NotificationOutbox" (
|
||||
"id" BIGSERIAL NOT NULL,
|
||||
"kind" TEXT NOT NULL,
|
||||
"caseId" TEXT,
|
||||
"channelId" TEXT,
|
||||
"recipientId" TEXT,
|
||||
"actorId" TEXT NOT NULL,
|
||||
"meta" JSONB,
|
||||
"createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
|
||||
"sentAt" TIMESTAMP(3),
|
||||
"attempts" INTEGER NOT NULL DEFAULT 0,
|
||||
"lastError" TEXT,
|
||||
|
||||
CONSTRAINT "NotificationOutbox_pkey" PRIMARY KEY ("id")
|
||||
);
|
||||
|
||||
CREATE INDEX "NotificationOutbox_sentAt_createdAt_idx"
|
||||
ON "NotificationOutbox"("sentAt", "createdAt");
|
||||
CREATE INDEX "NotificationOutbox_caseId_idx" ON "NotificationOutbox"("caseId");
|
||||
|
||||
-- Der Worker wartet nicht auf seinen Takt, wenn etwas anliegt.
|
||||
CREATE OR REPLACE FUNCTION notify_outbox() RETURNS trigger AS $$
|
||||
BEGIN
|
||||
PERFORM pg_notify('notification_queued', NEW."id"::text);
|
||||
RETURN NULL;
|
||||
END;
|
||||
$$ LANGUAGE plpgsql;
|
||||
|
||||
CREATE TRIGGER notification_outbox_notify
|
||||
AFTER INSERT ON "NotificationOutbox"
|
||||
FOR EACH ROW EXECUTE FUNCTION notify_outbox();
|
||||
@@ -41,10 +41,13 @@ model User {
|
||||
firstSeenAt DateTime @default(now())
|
||||
lastSeenAt DateTime @default(now())
|
||||
|
||||
/// Wie viel dieser Nutzer per Discord erfahren will.
|
||||
/// Siehe docs/06-chat-und-realtime.md.
|
||||
notifyMode NotifyMode @default(OWN_CASES)
|
||||
|
||||
roles UserRole[]
|
||||
sessions Session[]
|
||||
|
||||
personnelFiles PersonnelFile[]
|
||||
participations CaseParticipant[]
|
||||
assignments PersonnelAssignment[]
|
||||
@@ -55,9 +58,13 @@ model User {
|
||||
@@index([isActive, displayName])
|
||||
}
|
||||
|
||||
/// Was ein Nutzer per Discord erfahren will.
|
||||
enum NotifyMode {
|
||||
/// jede Aenderung in jeder Akte, die er sehen darf
|
||||
ALL
|
||||
/// nur Akten, an denen er beteiligt ist oder die er beobachtet
|
||||
OWN_CASES
|
||||
/// nur direkte Erwaehnungen
|
||||
MENTIONS
|
||||
OFF
|
||||
}
|
||||
@@ -720,6 +727,10 @@ model ChatMessage {
|
||||
withdrawnAt DateTime?
|
||||
/// Gesetzt, sobald die Nachricht als Vermerk uebernommen wurde.
|
||||
adoptedEntryId String?
|
||||
/// Erwaehnte Nutzer, beim Senden aufgeloest. Steht hier und wird nicht beim
|
||||
/// Lesen aus dem Text geparst, weil der Worker sie fuer die
|
||||
/// Benachrichtigungen braucht, ohne den Text zu kennen.
|
||||
mentions String[] @default([])
|
||||
createdAt DateTime @default(now())
|
||||
|
||||
case Case? @relation(fields: [caseId], references: [id], onDelete: Cascade)
|
||||
@@ -732,6 +743,7 @@ model ChatMessage {
|
||||
@@index([channelId, createdAt(sort: Desc)])
|
||||
@@index([authorId])
|
||||
@@index([replyToId])
|
||||
@@index([mentions], type: Gin)
|
||||
}
|
||||
|
||||
/// Kleiner fester Satz an Reaktionen, keine freie Emoji-Auswahl.
|
||||
@@ -766,6 +778,35 @@ model Watch {
|
||||
}
|
||||
|
||||
|
||||
/// Was die Web-App dem Worker zum Verschicken uebergibt.
|
||||
///
|
||||
/// Eine Tabelle statt eines direkten Aufrufs, weil der Worker ein eigener
|
||||
/// Prozess ist und laufen oder auch gerade neu starten kann. Ein Eintrag, der
|
||||
/// nicht rausging, bleibt liegen und wird beim naechsten Durchlauf abgeholt.
|
||||
/// Kein Einmal-Container, siehe CLAUDE.md, harte Regel 8.
|
||||
///
|
||||
/// **Hier steht nie ein Inhalt.** Nur Kennungen und die Art des Ereignisses;
|
||||
/// den Text baut der Worker daraus, und Discord kennt unsere Klassifizierung
|
||||
/// nicht. Siehe docs/06-chat-und-realtime.md.
|
||||
model NotificationOutbox {
|
||||
id BigInt @id @default(autoincrement())
|
||||
kind String // "entry.new", "chat.new", "chat.mention", "case.status"
|
||||
caseId String?
|
||||
channelId String?
|
||||
/// Leer heisst: in den allgemeinen Kanal. Sonst als Direktnachricht.
|
||||
recipientId String?
|
||||
actorId String
|
||||
/// Nur Kennungen und Zahlen, nie Text aus einer Akte.
|
||||
meta Json?
|
||||
createdAt DateTime @default(now())
|
||||
sentAt DateTime?
|
||||
attempts Int @default(0)
|
||||
lastError String?
|
||||
|
||||
@@index([sentAt, createdAt])
|
||||
@@index([caseId])
|
||||
}
|
||||
|
||||
/// Lebenszeichen der Dienste, die nicht im Web-Container laufen. Der Worker
|
||||
/// schreibt hier seinen Gateway-Zustand hinein, damit /api/health ihn pruefen
|
||||
/// kann, ohne Discord zu befragen. Siehe docs/11-betrieb.md.
|
||||
|
||||
Reference in New Issue
Block a user