Florian Wilde
b8166e10ea
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
31 lines
1.6 KiB
SQL
31 lines
1.6 KiB
SQL
-- ---------------------------------------------------------------------------
|
||
-- HANDGESCHRIEBEN. Prisma erzeugt hier zusaetzlich Loeschbefehle fuer die
|
||
-- zusammengesetzten Fremdschluessel (Mandantengrenze), die Trigramm-Indizes
|
||
-- (Archivsuche), die partiellen eindeutigen Indizes und die Trigger auf
|
||
-- veroeffentlichten Versionen: es kennt sie nicht, weil sie sich im Schema nicht
|
||
-- ausdruecken lassen. Diese Loeschbefehle sind bewusst gestrichen.
|
||
--
|
||
-- tests/datenbankregeln.test.ts prueft, dass alle diese Objekte vorhanden sind –
|
||
-- ein versehentlich stehengelassener Loeschbefehl faellt dort sofort auf.
|
||
-- ---------------------------------------------------------------------------
|
||
|
||
-- Abteilungsspezifische Zusatzabschnitte (#031).
|
||
--
|
||
-- Beim Onboarding in der Buchhaltung gehoeren Schritte dazu, die sonst niemand
|
||
-- braucht. Bisher hiess die Wahl: eine Vorlage je Abteilung pflegen, oder
|
||
-- Schritte, die fuer die meisten "nicht zutreffend" sind.
|
||
--
|
||
-- Namen und nicht Kennungen: der Abschnitt gehoert zur Version und muss ein
|
||
-- Umbenennen oder Archivieren einer Abteilung ueberleben.
|
||
ALTER TABLE "VorlagenAbschnitt"
|
||
ADD COLUMN "nurFuerAbteilungen" TEXT[] NOT NULL DEFAULT ARRAY[]::TEXT[];
|
||
|
||
-- Welche Abschnitte fuer einen Lauf gelten, beim Start festgeschrieben.
|
||
--
|
||
-- Leer heisst **alle**. Bestehende Laeufe bekommen damit genau ihr bisheriges
|
||
-- Verhalten, ohne Nachfuehrung: sie zeigen weiter jeden Abschnitt ihrer Version.
|
||
-- Festgeschrieben und nicht berechnet, weil ein archivierter Lauf genau die
|
||
-- Schritte zeigen muss, die damals abgearbeitet wurden.
|
||
ALTER TABLE "Lauf"
|
||
ADD COLUMN "geltendeAbschnitte" TEXT[] NOT NULL DEFAULT ARRAY[]::TEXT[];
|