Harlekin
aef3df0d44
Punkt 3 der Wünsche. Die Abteilung stand als Freitext in der Personalakte. Damit liess sich nichts fragen: „SHD", „Shd" und „Sicherheitsdienst" waren drei Abteilungen. Sie ist jetzt ein eigenes Modell, im Adminbereich verwaltbar, und die drei vorhandenen Freitexte sind in der Migration zu Abteilungen geworden. **Eine Fallakte trägt keine Abteilung.** Sie gehört zu einer, wenn eine beteiligte Person ihr angehört - abgeleitet über CaseParticipant und die Personalakte. Eine eingetragene Zuordnung wäre nach zwei Wochen falsch: Leute wechseln, Beteiligte kommen dazu, und niemand pflegt das nach. Dasselbe gilt für die Dokumente: ein Dokument unmittelbar an der Abteilung wäre halb verdrahtet, weil die Vorlagen über TemplateUse nur Fall- und Personalakte kennen. Die Abteilungsseite zeigt Mitglieder, abgeleitete Fälle und Dokumente, Vermerke, Chat und ein Kreisdiagramm der Fallarten; die Übersicht eines über alle Abteilungen. Das Diagramm ist serverseitig gerendertes SVG - eine Bibliothek wäre das Teuerste auf der Seite gewesen. Die Segmente sind Abstufungen von --steel und nicht die Stufenfarben: ein Tortenstück in Oxidrot würde als „streng geheim" gelesen. Die Zusammenfassung ist die gefährliche Stelle. Eine Abteilungsseite fasst zusammen, was einzeln längst geschützt ist, und eine Zusammenfassung, die nicht filtert, verrät mehr als jede Einzelansicht. Deshalb läuft hier jede Liste und jede Zahl durch dieselben Fragmente wie überall; ein Test prüft, dass die Summe der Diagrammanteile mit der Länge der Liste übereinstimmt. Wo jemand Personalakten gar nicht sehen darf, steht null und keine Null. Vermerke erben Regel 2 unverändert: kein DELETE, Version bei jeder Änderung, Grabstein bei jeder Zurücknahme, als Regel und Trigger in der Datenbank. Ohne Korrekturkette, Anhänge und Karenzzeit - was Beweiswert hat, gehört in eine Fallakte. Nebenbei: das Zugriffsprotokoll hängt jetzt am dafür vorgesehenen Recht audit.read statt an admin.
77 lines
2.2 KiB
TypeScript
77 lines
2.2 KiB
TypeScript
import { db } from '@/lib/db'
|
|
import type { Prisma } from '@afis/db'
|
|
|
|
/**
|
|
* Ereignisse an alle offenen Ansichten schicken.
|
|
*
|
|
* Über `pg_notify`, nicht über einen prozessinternen Verteiler: dann stimmt es
|
|
* auch, wenn später ein zweiter Web-Prozess dazukommt, und es braucht keinen
|
|
* zusätzlichen Dienst. Siehe docs/06-chat-und-realtime.md.
|
|
*
|
|
* **In der Nutzlast steht nie ein Inhalt**, nur ein Thema, eine Art und eine
|
|
* Kennung. Wer das Ereignis bekommt, entscheidet der Strom-Endpunkt, und was
|
|
* er daraus zu sehen bekommt, entscheidet die Sichtbarkeitsprüfung. Ein Text
|
|
* in der Nutzlast wäre an jedem Filter vorbei.
|
|
*/
|
|
|
|
export const STREAM_CHANNEL = 'afis_stream'
|
|
|
|
export type EventKind =
|
|
| 'chat.new'
|
|
| 'chat.edit'
|
|
| 'chat.withdrawn'
|
|
| 'chat.reaction'
|
|
| 'chat.adopted'
|
|
| 'entry.new'
|
|
| 'entry.updated'
|
|
| 'case.update'
|
|
| 'attachment.scanned'
|
|
| 'export.ready'
|
|
|
|
/** Wer das Ereignis angeht. */
|
|
export type Topic =
|
|
| `case:${string}`
|
|
| `personnel:${string}`
|
|
| `department:${string}`
|
|
| `user:${string}`
|
|
|
|
export function caseTopic(caseId: string): Topic {
|
|
return `case:${caseId}`
|
|
}
|
|
export function personnelTopic(fileId: string): Topic {
|
|
return `personnel:${fileId}`
|
|
}
|
|
export function departmentTopic(departmentId: string): Topic {
|
|
return `department:${departmentId}`
|
|
}
|
|
export function userTopic(userId: string): Topic {
|
|
return `user:${userId}`
|
|
}
|
|
|
|
export type StreamEvent = { t: Topic; k: EventKind; i: string }
|
|
|
|
export async function publish(
|
|
topic: Topic,
|
|
kind: EventKind,
|
|
id: string,
|
|
tx?: Prisma.TransactionClient,
|
|
): Promise<void> {
|
|
const payload = JSON.stringify({ t: topic, k: kind, i: id } satisfies StreamEvent)
|
|
try {
|
|
const client = tx ?? db
|
|
await client.$executeRaw`SELECT pg_notify(${STREAM_CHANNEL}, ${payload})`
|
|
} catch (error) {
|
|
// Ein verlorenes Ereignis kostet eine Aktualisierung von Hand, mehr nicht.
|
|
// Es ist kein Grund, die Änderung scheitern zu lassen, die es meldet.
|
|
console.error('[realtime] Ereignis nicht zugestellt', error)
|
|
}
|
|
}
|
|
|
|
/** Kurzform für die Prüfkette der Dateien, die nur ein Thema kennt. */
|
|
export async function notifyAttachmentScanned(
|
|
attachmentId: string,
|
|
topic: Topic,
|
|
): Promise<void> {
|
|
await publish(topic, 'attachment.scanned', attachmentId)
|
|
}
|