Phase 2 abgeschlossen: nachträgliche Änderungen, Grabstein, Richtlinie

Der Kern von harter Regel 2. Jede Änderung an einem Verlaufseintrag schreibt
den vorherigen Stand nach CaseEntryVersion und erhöht die Versionsnummer.
Autor und Entstehungszeit bleiben unangetastet, geprüft gegen die Datenbank.

Die Karenzzeit wird serverseitig aus AppSetting gelesen, nie aus dem Request.
Eine Änderung darin wird versioniert und protokolliert, aber nicht sichtbar
markiert - ein Tippfehler, zwei Minuten später korrigiert, soll die Akte nicht
mit "bearbeitet"-Marken zupflastern. Alles danach ist markiert und verlangt
eine Begründung, ebenso jede Änderung an einem fremden Eintrag.

Die Stelle, an der eine naive Umsetzung leckt, hat einen eigenen Test: wird
minClearance eines Eintrags angehoben, erben alle bestehenden Versionen den
neuen Wert. Sonst liest jemand mit niedrigerer Stufe den ursprünglichen Text
einfach in der Historie.

Zurückziehen setzt einen Grabstein mit Pflichtbegründung, der Text bleibt in
der Datenbank. Rückgängig machen geht und wird wiederum protokolliert.
Systemeinträge sind von jeder Änderung ausgenommen.

Dazu die Änderungsübersicht als Reiter an der Akte - sichtbar für alle, die
die Akte lesen dürfen, nicht nur für die Leitung - und die Adminseite für die
Änderungsrichtlinie.

Zwei Testprobleme dabei behoben: AppSetting ist eine einzige Zeile für die
ganze Anwendung, deshalb laufen die Web-Tests jetzt nacheinander, und die
Testdatenbank startet bei jedem Lauf im Auslieferungszustand. Vorher hing das
Ergebnis davon ab, was der vorige Lauf hinterlassen hatte.

63 Tests, zweimal hintereinander grün. Bündel bei 110,5 kB von 120.
This commit is contained in:
Harlekin
2026-09-01 23:11:42 +02:00
parent d7de8403ce
commit cb2088c4f2
15 changed files with 1362 additions and 26 deletions
@@ -0,0 +1,140 @@
'use client'
import { useState, useTransition } from 'react'
import { de } from '@/lib/i18n/de'
import { changeStatusAction, reclassifyAction } from '../actions'
/**
* Statuswechsel und Umklassifizierung.
*
* Bewusst **nicht** optimistisch: beides ist folgenreich und teils nicht
* umkehrbar. Stattdessen ein sofortiger Wartezustand am Knopf und eine klare
* Rückmeldung. Siehe docs/09-performance-und-ux.md.
*/
export function CaseActions({
caseNumber,
classification,
statusTargets,
levels,
maxLevel,
}: {
caseNumber: string
classification: number
statusTargets: string[]
levels: { level: number; name: string }[]
maxLevel: number
}) {
const [nextStatus, setNextStatus] = useState(statusTargets[0] ?? '')
const [statusReason, setStatusReason] = useState('')
const [nextLevel, setNextLevel] = useState(classification)
const [levelReason, setLevelReason] = useState('')
const [error, setError] = useState<string | null>(null)
const [pending, startTransition] = useTransition()
const lowering = nextLevel < classification
function run(action: () => Promise<{ ok: boolean; error?: string }>, confirmText: string) {
if (!confirm(confirmText)) return
setError(null)
startTransition(async () => {
const result = await action()
if (!result.ok) setError(result.error ?? de.case.errors.default!)
})
}
return (
<div className="mt-6 flex flex-wrap gap-x-10 gap-y-5 border-t border-line pt-5 text-xs">
{statusTargets.length > 0 ? (
<div>
<p className="font-condensed text-text-dim">{de.case.statusChange}</p>
<div className="mt-1.5 flex flex-wrap items-center gap-2">
<select
value={nextStatus}
onChange={(event) => setNextStatus(event.target.value)}
className="border border-line bg-raised px-2 py-1"
>
{statusTargets.map((target) => (
<option key={target} value={target}>
{de.case.statusNames[target] ?? target}
</option>
))}
</select>
<input
value={statusReason}
onChange={(event) => setStatusReason(event.target.value)}
placeholder={de.entry.changeReason}
className="w-56 border border-line bg-raised px-2 py-1"
/>
<button
type="button"
disabled={pending || !nextStatus}
onClick={() =>
run(
() =>
changeStatusAction({
caseNumber,
to: nextStatus,
reason: statusReason || undefined,
}),
`${de.case.statusChange}: ${de.case.statusNames[nextStatus] ?? nextStatus}?`,
)
}
className="border border-line bg-raised px-3 py-1 font-condensed text-accent disabled:text-text-dim"
>
{pending ? de.case.saving : de.common.save}
</button>
</div>
</div>
) : null}
<div>
<p className="font-condensed text-text-dim">{de.case.reclassify}</p>
<div className="mt-1.5 flex flex-wrap items-center gap-2">
<select
value={nextLevel}
onChange={(event) => setNextLevel(Number(event.target.value))}
className="border border-line bg-raised px-2 py-1"
>
{levels
.filter((level) => level.level <= maxLevel)
.map((level) => (
<option key={level.level} value={level.level}>
{level.level} · {level.name}
</option>
))}
</select>
{/* Eine Herabstufung macht Inhalte für Leute sichtbar, die sie vorher
nicht sehen durften. Deshalb ist die Begründung Pflicht. */}
{lowering ? (
<input
value={levelReason}
onChange={(event) => setLevelReason(event.target.value)}
placeholder={de.case.reclassifyReason}
className="w-64 border border-line bg-raised px-2 py-1"
/>
) : null}
<button
type="button"
disabled={pending || nextLevel === classification}
onClick={() =>
run(
() =>
reclassifyAction({
caseNumber,
to: nextLevel,
reason: levelReason || undefined,
}),
`${de.case.reclassify}: ${nextLevel}?`,
)
}
className="border border-line bg-raised px-3 py-1 font-condensed text-accent disabled:text-text-dim"
>
{pending ? de.case.saving : de.common.save}
</button>
</div>
</div>
{error ? <p className="w-full font-condensed text-2xs text-stamp-4">{error}</p> : null}
</div>
)
}