Workspace: Calls & Meeting-Protokolle -- Phase 3 vollstaendig

/workspace/calls.html.

Calls sind KEINE eigene Terminart neben dem Kalender, sondern dieselben
Termine mit art = 'call' oder 'review'. Ein zweiter Terminspeicher waere
die sichere Art, irgendwann zwei widerspruechliche Uhrzeiten zu haben.
Diese Seite fuegt nur hinzu, was ein Gespraech vom blossen Termin
unterscheidet: das Protokoll danach. Die Sichtbarkeitsregel ist Wort fuer
Wort dieselbe wie im Kalender -- ein Termin darf nicht in der einen
Ansicht auftauchen und in der anderen fehlen.

Der tragende Satz von Seite 13, woertlich genommen:
"Jeder Call endet mit klaren To-dos, die direkt ins Board uebernommen
werden."

To-dos werden deshalb NICHT als Text im Protokoll abgelegt, sondern
sofort zu echten Aufgaben -- mit dem Gespraech als Herkunft in der
Beschreibung, zugeordnet an das Gegenueber des Calls. Sonst steht die
Verabredung in einem Dokument, das niemand mehr oeffnet. Geprueft:
Protokoll geschrieben -> Aufgaben stehen im Brett.

Weitere Punkte:

- Reihenfolge der Gruppen ist Dringlichkeit, nicht Chronologie: Ganz oben
  stehen vergangene Gespraeche OHNE Protokoll. Das ist der einzige
  Zustand, der etwas von einem verlangt. Nur diese Gruppe ist optisch
  hervorgehoben; wenn alles schreit, sieht man nichts mehr.
- Ein festgehaltenes Protokoll ist danach nur noch lesbar. Ein Gespraech
  nachtraeglich umschreiben zu koennen waere genau das, was ein Protokoll
  wertlos macht.
- "Naechster Termin" legt den Folgetermin direkt in den Kalender -- mit
  demselben Gegenueber und demselben Meeting-Link.
- Alles in EINER Transaktion. Geprueft mit einem absichtlich kaputten
  To-do: kein Protokoll, keine halben Aufgaben, kein Folgetermin.
- Enter im To-do-Feld legt die naechste Zeile an, damit man eine Liste
  tippen kann, ohne zur Maus zu greifen.
- Meeting-Link nur bei anstehenden Gespraechen und nur, wenn es wirklich
  eine http(s)-Adresse ist. "bei mir zu Hause" bleibt schlichter Text.

Zur Videotechnik selbst bewusst KEINE Entscheidung getroffen: Ein eigener
WebRTC-Raum braucht einen TURN-Server, damit Verbindungen hinter
Mobilfunk-NAT zustande kommen. Das ist eine Infrastrukturfrage mit
laufenden Kosten und gehoert besprochen, nicht nebenbei entschieden.
Bis dahin traegt der Termin einfach den Link des Dienstes, der ohnehin
benutzt wird.

Nebenbei: .knopf-still lag in scouting.css und fehlte dadurch auf
calls.html -- dort standen prompt nackte Systemknoepfe. Der Baustein
gehoert ins gemeinsame start.css, dort liegt er jetzt.

server/workspace.js

@@ -222,6 +222,32 @@ export function db() {
       );
       CREATE INDEX IF NOT EXISTS idx_eintraege_bereich ON eintraege (bereich, creator_id);
 
+      /* Meeting-Protokoll zu einem Termin (Konzept, Seite 13).
+         Bewusst eine eigene Tabelle statt neuer Spalten in termine: Es
+         gibt hier keine Migrationen, und ein Protokoll gehoert ohnehin
+         nur zu einem Bruchteil der Termine. Ein Termin hat hoechstens
+         ein Protokoll -- daher UNIQUE. */
+      CREATE TABLE IF NOT EXISTS protokolle (
+        id                  INTEGER PRIMARY KEY AUTOINCREMENT,
+        termin_id           INTEGER NOT NULL UNIQUE REFERENCES termine(id) ON DELETE CASCADE,
+        punkte              TEXT,
+        entscheidungen      TEXT,
+        naechster_termin_id INTEGER REFERENCES termine(id) ON DELETE SET NULL,
+        erstellt            TEXT NOT NULL,
+        erstellt_von        INTEGER REFERENCES personen(id) ON DELETE SET NULL,
+        geaendert           TEXT
+      );
+
+      /* "Jeder Call endet mit klaren To-dos, die direkt ins Board
+         uebernommen werden." Die To-dos leben deshalb NICHT im Protokoll,
+         sondern sind echte Aufgaben. Diese Tabelle merkt sich nur, aus
+         welchem Gespraech eine Aufgabe entstanden ist. */
+      CREATE TABLE IF NOT EXISTS protokoll_aufgaben (
+        protokoll_id INTEGER NOT NULL REFERENCES protokolle(id) ON DELETE CASCADE,
+        aufgabe_id   INTEGER NOT NULL REFERENCES aufgaben(id) ON DELETE CASCADE,
+        PRIMARY KEY (protokoll_id, aufgabe_id)
+      );
+
       /* Scout-CRM: die Pipeline vom ersten Fund bis zur Uebergabe.
          creator_id ist gesetzt, sobald aus einem uebergebenen Lead eine
          echte Person angelegt wurde -- damit bleibt nachvollziehbar, wer
@@ -387,6 +413,7 @@ const GESCHUETZT = {
   "/workspace/bereich.html": ["admin", "creator"],
   "/workspace/report.html": ["admin", "creator"],
   "/workspace/scouting.html": ["admin", "scout"],
+  "/workspace/calls.html": null,
 };
 
 workspaceRouter.use((req, res, next) => {