Harlekin
03cb5ec9a7
Die Dokumentebene aus docs/13 ist gebaut, additiv: Document, DocumentSection und DocumentSectionVersion neben Case, CaseSection und CaseEntry. Ein Dokument hängt an einer Fallakte, an einer Personalakte oder an nichts, höchstens an einem - gesichert durch eine CHECK-Bedingung. Es gibt kein DELETE; eine Zurücknahme lässt einen Grabstein stehen, der auch für den Admin zu ist. Eine neue Dokumentart ist damit ein Datensatz, kein Deployment. Im Seed stehen vier: vermerk, vorfallsbericht, sonderarbeitsvertrag (mehrseitiger Vertragstext mit Platzhaltern und Unterschriftenzeilen) und bussgeld. Zwei Umbenennungen, beide von Hand migriert, damit die vorhandenen Zeilen und Zählerstände stehen bleiben: - CaseTemplate -> DocumentTemplate, plus uses[] und layout - CaseCounter -> NumberSeries, ein Nummernkreis je Präfix für Aktenzeichen und Dokumentnummern Die Regeln für Abschnitte stehen jetzt einmal in lib/sections/render.ts und gelten für Fallakten und Dokumente gleichermaßen. Die Frage aus docs/13, ob CaseSection langfristig in die Dokumentebene wandert, ist damit verneint und begründet. Rückverweise auf der Personalakte laufen durch visibleCaseWhere, die Zahl daneben entsteht aus dem gefilterten Ergebnis. Auch die Rollengruppe verschwindet mit, sonst verriete "Betroffener" ohne Eintrag die Ermittlung. Die eigene Personalakte ist keine Ausnahme von der Freigabestufe. Vier neue Rechte: document.create, .edit, .finalize, .retract. Das letzte steht bei den zurückgehaltenen, es greift in Geschriebenes ein. 91 Tests im Web-Paket, 15 in der Datenbank, 28 e2e. Größte Route 118 kB gegen das Budget von 120 kB - die Luft wird knapp.
68 lines
1.8 KiB
TypeScript
68 lines
1.8 KiB
TypeScript
/**
|
|
* Rechte-Enum aus docs/03-auth-und-rechte.md. RoleMapping.permissions ist in der
|
|
* Datenbank ein String[], diese Liste ist die verbindliche Menge gültiger Werte
|
|
* und die Grundlage der Kästchen im Adminbereich.
|
|
*/
|
|
export const PERMISSIONS = [
|
|
'case.read',
|
|
'case.create',
|
|
'case.edit',
|
|
'case.close',
|
|
'case.reopen',
|
|
'case.edit_closed',
|
|
'entry.create',
|
|
'entry.correct',
|
|
'entry.edit_own',
|
|
'entry.edit_any',
|
|
'entry.retract',
|
|
'personnel.read',
|
|
'personnel.edit',
|
|
'document.create',
|
|
'document.edit',
|
|
'document.finalize',
|
|
'document.retract',
|
|
'template.manage',
|
|
'roles.manage',
|
|
'audit.read',
|
|
'export.approve',
|
|
'admin',
|
|
] as const
|
|
|
|
export type Permission = (typeof PERMISSIONS)[number]
|
|
|
|
/**
|
|
* Diese drei sind im Auslieferungszustand keiner Rolle zugeordnet. Der Leiter
|
|
* schaltet sie bewusst frei. Der Adminbereich weist beim Zuweisen darauf hin.
|
|
*/
|
|
export const OPT_IN_PERMISSIONS: readonly Permission[] = [
|
|
'entry.edit_own',
|
|
'entry.edit_any',
|
|
'entry.retract',
|
|
'document.retract',
|
|
]
|
|
|
|
export function isPermission(value: string): value is Permission {
|
|
return (PERMISSIONS as readonly string[]).includes(value)
|
|
}
|
|
|
|
/** Aufgelöste Rechte eines Nutzers für genau einen Request. */
|
|
export type EffectivePermissions = {
|
|
userId: string
|
|
/** Höchste Stufe aller Rollen. */
|
|
clearanceLevel: number
|
|
/** Vereinigung aller Rollen. */
|
|
permissions: Set<Permission>
|
|
/** Aus BOOTSTRAP_ADMIN_IDS oder Recht 'admin'. */
|
|
isAdmin: boolean
|
|
/**
|
|
* Trägt der Nutzer eine Rolle, die zur Anmeldung berechtigt? Ergänzung
|
|
* gegenüber docs/03-auth-und-rechte.md: auf dem AfiS-Discord sind auch
|
|
* Gäste. Siehe docs/13-entscheidungen.md.
|
|
*/
|
|
hasMembership: boolean
|
|
}
|
|
|
|
export function can(p: EffectivePermissions, permission: Permission): boolean {
|
|
return p.isAdmin || p.permissions.has(permission)
|
|
}
|