- Termin aus Mail: Mailtext oder .eml per Drag & Drop/Strg+V auf Terminplan oder Aufgaben, KI schlägt Aufgaben vor, Prüfung im Aufgaben-Panel; neues Notizfeld je Aufgabe (plan_todos.notiz) - Terminplan: Meilensteine ohne Aufgabenbezug je in eigener Zeile, "+ Neu"-Menü klappt neben schmaler Seitenleiste nach rechts, Leistungsphasen - Rollen & Rechte, Abwesenheiten-Seite, Benachrichtigungen, Rundgang - Glas-Darstellung, Logo als Favicon - Pi-Betrieb: PDF-Arbeit im Kindprozess, Wächter, Einrichtungs- und Prüfskript inkl. WLAN-Wächter Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
97 lines
4.8 KiB
JavaScript
97 lines
4.8 KiB
JavaScript
// -----------------------------
|
|
// Projektplan — Verlauf über mehrere Sitzungen
|
|
// -----------------------------
|
|
// Dieses Modul liefert die Fassungen eines Projekts über die Sitzungen
|
|
// (Vorwochen-Helfer für den GANTT). Angezeigt wird der Kommentar-Verlauf
|
|
// im Projekt-Dashboard von plan-info.js.
|
|
//
|
|
// Der Verlauf in Wochenbericht und Projektliste wird von
|
|
// renderProjektVerlauf() in js/utils.js gezeichnet. Zuvor
|
|
// hatte jede dieser Stellen ihre eigene Fassung mit eigener Auswahl (hier nur
|
|
// Sitzungen mit Kommentarwechsel, im Bericht auch Termine und
|
|
// Leistungsphasen), weshalb derselbe Projektverlauf je nach Aufrufort anders
|
|
// aussah und sich widersprechen konnte.
|
|
//
|
|
// Hintergrund: Beim wöchentlichen cloneWeek() (js/weeks.js) wird der
|
|
// Kommentartext in die neue Sitzung kopiert und dort überschrieben. Der alte
|
|
// Text bleibt zwar in der alten Sitzung erhalten, war aber praktisch
|
|
// unsichtbar, weil niemand in alte Sitzungen zurückwechselt. Damit ging der
|
|
// Gesprächsfaden eines Projekts verloren — genau das, wofür das wöchentliche
|
|
// Board ursprünglich gedacht war.
|
|
//
|
|
// WICHTIG — kein neuer Endpunkt nötig: Die Projektplan-Seite lädt über
|
|
// GET /load-all ohnehin ALLE Sitzungen mit allen Projekten nach db.weeks
|
|
// (siehe loadPlanData() in plan-state.js). Zusammen mit project_uid (der
|
|
// dauerhaften, wochenunabhängigen Projekt-Identität, siehe
|
|
// migrateAddProjectUid() in server.js) lässt sich der Verlauf daher rein im
|
|
// Browser zusammenstellen. Ein serverseitiges GET /projects/:uid/history wird
|
|
// erst nötig, wenn der Verlauf auch außerhalb dieser Seite gebraucht wird.
|
|
//
|
|
// Die hier definierten Helfer projectVersions()/previousProjectVersion()
|
|
// werden auch von plan-build-gantt.js gebraucht (Geister-Balken der Vorwoche)
|
|
// und deshalb auf window.PlanApp exportiert. Dieses Modul muss daher VOR
|
|
// plan-build-gantt.js geladen werden.
|
|
//
|
|
// Läuft wie alle plan-Module in einem IIFE; Zustand: window.PlanApp
|
|
// (plan-state.js).
|
|
|
|
(function(){
|
|
const app = window.PlanApp;
|
|
|
|
// projectVersions: alle Fassungen des aktuellen Projekts über alle
|
|
// geladenen Sitzungen, chronologisch aufsteigend. Die eigentliche Logik
|
|
// liegt seit der Kommentar-Überarbeitung in js/utils.js
|
|
// (projectVersionsForUid), weil das Board sie ebenfalls braucht; hier bleibt
|
|
// nur die Bindung an das aktuell geöffnete Projekt.
|
|
function projectVersions(){
|
|
return projectVersionsForUid(app.project && app.project.projectUid);
|
|
}
|
|
|
|
// previousProjectVersion: die Fassung des Projekts aus der Sitzung
|
|
// unmittelbar VOR der gerade geöffneten, oder null (früheste Sitzung bzw.
|
|
// kein projectUid). Rückgabe: { week, project } | null.
|
|
function previousProjectVersion(){
|
|
const versions = projectVersions();
|
|
const idx = versions.findIndex(v => app.week && v.week.label === app.week.label);
|
|
return idx > 0 ? versions[idx - 1] : null;
|
|
}
|
|
|
|
// previousPlannedProjectVersion: die jüngste frühere Fassung, die überhaupt
|
|
// einen befüllten Terminplan hat (mindestens eine Aufgabe oder einen
|
|
// Meilenstein). Grundlage für die Geister-Balken im GANTT.
|
|
//
|
|
// Warum nicht einfach previousProjectVersion(): In der Praxis gibt es
|
|
// Sitzungen, in denen ein Projekt zwar geführt wird, aber (noch) keinen
|
|
// Terminplan hat — etwa weil die Sitzung neu angelegt statt dupliziert
|
|
// wurde. Ein Vergleich gegen so eine leere Fassung würde gar nichts
|
|
// anzeigen und die Funktion wirkte kaputt, obwohl es zwei Sitzungen weiter
|
|
// hinten sehr wohl Vergleichsdaten gibt. Deshalb wird rückwärts gesucht,
|
|
// bis eine Fassung mit Planinhalt gefunden ist. Die gefundene Sitzung wird
|
|
// in den Tooltips namentlich genannt, damit der Bezug nie unklar ist.
|
|
// Rückgabe: { week, project } | null.
|
|
function previousPlannedProjectVersion(){
|
|
const versions = projectVersions();
|
|
const idx = versions.findIndex(v => app.week && v.week.label === app.week.label);
|
|
if(idx <= 0) return null;
|
|
for(let i = idx - 1; i >= 0; i--){
|
|
const plan = versions[i].project.plan;
|
|
if(!plan) continue;
|
|
const hasTodos = Array.isArray(plan.todos) && plan.todos.length > 0;
|
|
const hasMilestones = Array.isArray(plan.milestones) && plan.milestones.length > 0;
|
|
if(hasTodos || hasMilestones) return versions[i];
|
|
}
|
|
return null;
|
|
}
|
|
|
|
// Die Kompakt-Karte "Verlauf" (renderPlanHistory()) und der Dialog
|
|
// #planHistoryModal (openHistoryModal()/closeHistoryModal()) sind entfallen:
|
|
// Der Kommentar-Verlauf steht jetzt in der Kachel "Kommentar der Sitzung"
|
|
// des Projekt-Dashboards (renderPlanKommentarVerlauf(), plan-info.js).
|
|
|
|
// Export für die anderen plan-Module (plan-gantt.js/plan-build-gantt.js:
|
|
// Geister-Balken der letzten geplanten Sitzung).
|
|
app.projectVersions = projectVersions;
|
|
app.previousProjectVersion = previousProjectVersion;
|
|
app.previousPlannedProjectVersion = previousPlannedProjectVersion;
|
|
})();
|