Phase 2 stand bisher nur als acht Stichpunkte im Epic. Jetzt je Meilenstein eine Datei mit Ziel, Aufgaben und Akzeptanzkriterien, dazu im Tracker gespiegelt: #48 bis #55, zusammen 76 h geschaetzt. Die Reihenfolge ist nicht beliebig. M15 fuehrt die Quellenart ein, die M16 braucht; M17 legt die Zusammensetzung fest, auf der M18 aufsitzt. Die anderen vier haengen an nichts und koennen jederzeit dazwischen. Drei Entscheidungen fallen vor dem Code und stehen je Meilenstein als erste Aufgabe mit Empfehlung: - Wie ein Baustein die Unveraenderlichkeit einer veroeffentlichten Version ueberlebt (Verweis im Entwurf, tiefe Kopie beim Veroeffentlichen). Ein Lauf sieht weiterhin konkrete Schritte und muss nichts lernen. - Wo Anhaenge liegen (Dateisystem, Metadaten in der Datenbank) -- mit der Folge, dass Compose-Stand, native Installation und sicherung.md ein Volume brauchen. Eine Sicherung, die nur die Datenbank mitnimmt, verliert ab dort Daten. - Was eine Selbstauskunft zeigt: Titel, Status, Zeitraum, Geraet, aber keine Schritte, Notizen, Kommentare oder Anhaenge. In einem Lauf stehen Arbeitsnotizen ueber Menschen; eine Selbstauskunft ist keine Akteneinsicht. Refs #2
60 lines
3.2 KiB
Markdown
60 lines
3.2 KiB
Markdown
# #030 M17 – Wiederverwendbare Bausteine
|
||
|
||
**Status:** offen
|
||
**Im Tracker:** [#50](https://git.wilde-server.de/florian.wilde/Laufzettel/issues/50)
|
||
**Meilenstein:** v0.2.0
|
||
**Labels:** phase-2, backend, frontend
|
||
**Geschätzt:** 12 h **Tatsächlich:** –
|
||
|
||
## Ziel
|
||
|
||
„Datensicherung prüfen“ steht in vier der sieben Vorlagen, wortgleich. Wer den Ablauf ändert, ändert
|
||
ihn heute viermal — oder dreimal und vergisst den vierten. Ein **Baustein** ist ein Abschnitt, den
|
||
mehrere Vorlagen teilen.
|
||
|
||
## Woran es hängt
|
||
|
||
Eine veröffentlichte `VorlagenVersion` ist **unveränderlich**. Das trägt die Nachvollziehbarkeit des
|
||
ganzen Archivs: ein Lauf zeigt auch in zehn Jahren genau die Schritte, die damals abgearbeitet
|
||
wurden. Ein Baustein, der sich ändert, darf das nicht antasten.
|
||
|
||
## Zu entscheiden
|
||
|
||
- [ ] **Baustein mit eigener Version, beim Veröffentlichen tief kopiert** — Empfehlung. Ein
|
||
Entwurf **verweist** auf einen Baustein; beim Veröffentlichen löst der Dienst den Verweis in
|
||
echte Abschnitte und Schritte auf. Damit bleibt alles, was danach kommt, unberührt: `Lauf`,
|
||
`Schrittergebnis`, Druckansicht und Archiv sehen weiterhin konkrete Schritte und müssen nichts
|
||
lernen.
|
||
Die Alternative — Läufe verweisen zur Laufzeit auf den Baustein — hieße, dass die Unveränder-
|
||
lichkeit an einer zweiten Stelle durchgesetzt werden muss, und dass jede Abfrage über Schritte
|
||
zwei Wege kennen muss. Das ist der Preis für eine Bequemlichkeit, die niemand verlangt hat.
|
||
- [ ] **Was „Baustein aktualisieren“ für laufende Arbeiten bedeutet:** nichts. Eine neue
|
||
Baustein-Version wirkt erst in der **nächsten** veröffentlichten Vorlagenversion. Das muss die
|
||
Oberfläche sagen, sonst erwartet man Durchschlag.
|
||
|
||
## Aufgaben
|
||
|
||
- [ ] Modelle `Baustein` und `BausteinVersion` mit denselben Regeln wie bei Vorlagen: höchstens ein
|
||
Entwurf, veröffentlichte Version unveränderlich (Trigger, nicht nur Dienst)
|
||
- [ ] `VorlagenAbschnitt` kann statt eigener Schritte einen Baustein nennen — nur im **Entwurf**
|
||
- [ ] Veröffentlichen löst auf: tiefe Kopie der Baustein-Abschnitte und -Schritte in die Version,
|
||
mit Vermerk, aus welchem Baustein und welcher Version sie stammen
|
||
- [ ] Editor: Baustein einfügen, als Einheit anzeigen, nicht Schritt für Schritt bearbeitbar; ein
|
||
Hinweis nennt Baustein und Version
|
||
- [ ] Eigene Verwaltung für Bausteine, Recht `vorlagenBearbeiten` (wer Vorlagen pflegt, pflegt
|
||
Bausteine)
|
||
- [ ] „Wo wird dieser Baustein benutzt“ — vor dem Ändern will man das wissen
|
||
- [ ] Anleitung Kapitel 04
|
||
|
||
## Akzeptanzkriterien
|
||
|
||
- [ ] Test: eine neue Baustein-Version ändert **keine** veröffentlichte Vorlagenversion und **keinen**
|
||
laufenden Lauf
|
||
- [ ] Test: die Druckansicht eines archivierten Laufs ist nach einer Baustein-Änderung Zeichen für
|
||
Zeichen dieselbe
|
||
- [ ] Test: die nächste veröffentlichte Vorlagenversion enthält die neue Baustein-Version
|
||
- [ ] Test: ein Baustein lässt sich nicht löschen, solange eine Vorlage ihn im Entwurf nennt
|
||
- [ ] Test: Export und Import einer Vorlage mit Baustein ergeben eine inhaltsgleiche Vorlage — die
|
||
Datei trägt die aufgelösten Schritte, keinen Verweis auf einen Baustein, den die andere
|
||
Installation nicht hat
|