Beim Onboarding in der Buchhaltung gehoeren Schritte dazu, die sonst niemand braucht: DATEV, Drucker fuer Formulare, Bankportal. Bisher hiess die Wahl: eine Vorlage je Abteilung pflegen, oder Schritte, die fuer die meisten "nicht zutreffend" sind. Jeder Abschnitt kann jetzt nennen, fuer welche Abteilungen er gilt -- als **Namen**, nicht als Kennungen. Der Abschnitt gehoert zur Version und muss ein Umbenennen oder Archivieren einer Abteilung ueberleben; dieselbe Entscheidung wie bei Mitarbeiter.abteilung. Deshalb wandert die Einschraenkung auch durch Export und Import. Welche Abschnitte ein Lauf hat, wird beim Start festgeschrieben. Ein spaeterer Abteilungswechsel aendert ihn nicht -- sonst verschwaende ein Schritt, an dem schon eine Notiz haengt, und ein archivierter Lauf muss genau das zeigen, was damals abgearbeitet wurde. Leer heisst alle: Laeufe von vor dieser Fassung verhalten sich unveraendert, ohne dass eine Migration Daten nachfuehren muesste. Damit das eindeutig bleibt, wird ein Lauf abgewiesen, fuer den kein Abschnitt uebrig bleibt -- es gaebe ohnehin nichts abzuarbeiten. Die Abschlussregel zaehlt nur geltende Pflichtschritte. Vorher waere der Abschluss unerreichbar gewesen: abhaken laesst sich nur, was in der Abarbeitung steht. Der Test hat das sofort gezeigt. Die Regel liegt in src/lib, weil drei Schichten sie brauchen -- der Dienst beim Start und beim Abschluss, die Lesemodelle der Abarbeitung und des Drucks. In einem Lesemodell waere sie eine Abhaengigkeit in die falsche Richtung. Im gebauten Stand durchgeklickt: einschraenken, speichern, veroeffentlichen, zwei Laeufe mit verschiedenen Abteilungen starten -- 6 Abschnitte mit 23 Schritten fuer die Buchhaltung, 5 mit 20 fuer den Vertrieb. Dabei einen eigenen Numerusfehler im Hinweistext gefunden und behoben. Closes #51
4.2 KiB
4.2 KiB
#031 M18 – Abteilungsspezifische Zusatzabschnitte
Status: erledigt Im Tracker: #51 Meilenstein: v0.2.0 Labels: phase-2, backend, frontend Geschätzt: 8 h Tatsächlich: 1 h 35 min
Ziel
Beim Onboarding in der Buchhaltung gehören drei Schritte dazu, die sonst niemand braucht: DATEV einrichten, Drucker für Formulare, Zugang zum Bankportal. Heute heißt die Wahl: drei Vorlagen je Abteilung pflegen, oder Schritte, die für die meisten „nicht zutreffend“ sind.
Ein Abschnitt soll sagen können: nur für diese Abteilungen.
Zu entscheiden
- Die Auswahl wird beim Start festgeschrieben — Empfehlung. Der Lauf merkt sich, welche
Abschnitte für ihn gelten, statt sie bei jedem Aufruf aus
Lauf.abteilungIdneu zu berechnen. Grund: ein archivierter Lauf muss genau die Schritte zeigen, die damals abgearbeitet wurden. Wechselt jemand später die Abteilung des Laufs, dürfen Schritte nicht verschwinden, an denen schon eine Notiz hängt. - Was bei einem Lauf ohne Abteilung gilt: nur die Abschnitte ohne Einschränkung. Ein Firewall-Rollout hat keine Abteilung, und das ist kein Mangel.
Aufgaben
VorlagenAbschnitt.nurFuerAbteilungen— Liste von Abteilungsnamen, nicht von Kennungen: der Abschnitt gehört zur Version und muss ein Umbenennen oder Archivieren einer Abteilung überleben, ohne ins Leere zu zeigen. Dieselbe Entscheidung wie beiMitarbeiter.abteilung- Beim Start: die geltenden Abschnitte ermitteln und am Lauf festhalten
- Die Abarbeitungsansicht zeigt nur geltende Abschnitte; die Nummerierung (
01 ·) zählt nur sie - Die Abschlussregel zählt nur geltende Pflichtschritte. Ein ausgefilterter Pflichtschritt darf einen Lauf nicht blockieren — sonst ist der Abschluss unerreichbar
- Druckansicht und Archiv zeigen dieselbe Auswahl wie die Abarbeitung
- Editor: je Abschnitt eine Mehrfachauswahl über die gepflegten Abteilungen, mit Freitext für eine, die es noch nicht gibt
- Der Start-Dialog sagt vorher, wie viele Abschnitte die gewählte Abteilung hinzunimmt
- Anleitung Kapitel 04 und 02
Akzeptanzkriterien
- Test: ein Lauf für „Buchhaltung“ enthält den Buchhaltungs-Abschnitt, einer für „Vertrieb“ nicht
- Test: ein Lauf ohne Abteilung enthält nur die uneingeschränkten Abschnitte
- Test: die Abteilung eines laufenden Laufs ändern ändert nicht seine Abschnitte
- Test: ein ausgefilterter Pflichtschritt blockiert den Abschluss nicht
- Test: die Druckansicht zeigt genau die Abschnitte der Abarbeitung — nicht mehr und nicht weniger
- Am Handy kein horizontales Scrollen
Beim Umsetzen dazugekommen
- Festgeschrieben wird über
Lauf.geltendeAbschnitte, und leer heißt „alle". Damit verhalten sich Läufe von vor dieser Fassung unverändert, ohne dass eine Migration Daten nachführen müsste. Ein neuer Lauf trägt immer alle geltenden Kennungen — auch wenn nichts eingeschränkt ist, denn sonst wäre „leer" zweideutig. - Ein Lauf, für den kein Abschnitt übrig bleibt, wird abgewiesen. Das war nötig, damit „leer heißt alle" eindeutig bleibt — und es ist ohnehin richtig: es gäbe nichts abzuarbeiten.
- Die Abschlussregel musste nachziehen.
offenePflichtschrittezählte den ausgefilterten Pflichtschritt weiter mit; der Abschluss wäre unerreichbar gewesen, weil sich nur abhaken lässt, was in der Abarbeitung steht. Der Test hat das sofort gezeigt. - Die Regel liegt in
src/lib/geltende-abschnitte.ts, nicht in einem der Lesemodelle: drei Schichten brauchen sie — der Dienst beim Start und beim Abschluss, und die Lesemodelle der Abarbeitung und der Druckansicht. Lebte sie in einem Lesemodell, importierte ein Dienst daraus, und das wäre eine Abhängigkeit in die falsche Richtung. - Ein Baustein-Abschnitt lässt sich genauso einschränken wie jeder andere: die Einschränkung gehört zur Vorlage, nicht zum Baustein.
- Eigener Numerusfehler beim Durchklicken gefunden: „Ein Abschnitt gilt … und bleiben weg." Korrigiert — alles, was ein Mensch liest, schreibt sich richtig (CLAUDE.md).