3 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGit	5684ff87f1	Workspace: "Was ist dran" -- erster Baustein der Automationen (Phase 4) ... Bis hierher musste man selbst daran denken, in den richtigen Bereich zu schauen. Das dreht die Uebersicht auf dem Dashboard jetzt um: Das System sagt, was liegen bleibt. Drei Regeln, an die sich das haelt: 1. KEINE eigenen Daten. Ein Hinweis ist immer nur eine Sicht auf etwas, das ohnehin existiert. Wird die Aufgabe erledigt, verschwindet der Hinweis von selbst -- es gibt nichts zu quittieren, nichts zu pflegen und nichts, was veralten kann. Genau daran scheitern die meisten Erinnerungssysteme. 2. JEDER HINWEIS FUEHRT IRGENDWOHIN. Ein Hinweis ohne Ziel ist nur ein schlechtes Gewissen. Jeder traegt deshalb einen Link zu der Stelle, an der sich die Sache tatsaechlich erledigen laesst. Geprueft: Ziel erreichbar, keine Umleitung. 3. DIESELBE SICHTBARKEIT WIE UEBERALL. Die Regeln werden aus den Fachmodulen importiert, nicht abgeschrieben (workspace-aufgaben, -kalender, -dateien, -bereiche exportieren sie jetzt). Ein Hinweis darf nie etwas verraten, das die zugehoerige Seite verbergen wuerde -- sonst waere ausgerechnet die Uebersicht das Leck. Dreizehn Hinweisarten, in drei Stufen. Nur die oberste ist farbig: waere alles hervorgehoben, waere nichts hervorgehoben. Liegt nichts an, verschwindet der ganze Block. Steht bewusst VOR den Zahlen. Die Zahlen sagen, WIE VIEL anliegt -- diese Liste sagt, WAS zu tun ist. Steuerungswissen bleibt beim Management: Review-Termine, Creator ohne zustaendige Person und leere Profile erscheinen weder bei Creator noch bei Scouts -- genau wie die zugehoerigen Profilfelder. Geprueft mit einem eigenen Leck-Test ueber alle drei Rollen. Zwei Hinweise, die es ohne diese Uebersicht gar nicht gaebe: - Aufgaben, die im Review haengen. Sie warten auf jemanden -- die Sorte Stillstand, die niemandem auffaellt, weil nichts ueberfaellig wird. - Uebergebene Leads, aus denen nie ein Creator wurde. Sonst ist die Uebergabe eine Sackgasse, die niemand bemerkt. Nebenbei: Der Fusstext auf dem Dashboard stammte noch vom ersten Tag ("Die Bereiche werden nach dem Phasenplan gebaut") -- inzwischen sind Phase 1 bis 3 fertig. Ersetzt durch eine Erklaerung, wie die Uebersicht funktioniert.	2026-08-28 11:23:07 +02:00
DogFatherGit	fa8fbab410	Workspace: Scouts betreuen Creator wie das Management ... Bisher hatten Scouts mit der Creator-Betreuung nichts zu tun -- keine Profile, keine Betreuungsbereiche, keine Reports. Das aendert sich, mit zwei bewusst gesetzten Grenzen. GRENZE 1: nur zugeteilte Creator, keine Rollenregel. Neue Tabelle betreuung (creator_id PRIMARY KEY -> betreuer_id). Ein Creator hat genau EINE zustaendige Person, damit nie unklar ist, wer gefragt ist. Das Management sieht ohnehin alle und braucht keinen Eintrag. Wer nichts zugeteilt bekommt, sieht weiterhin nichts -- kein Recht entsteht automatisch aus der Rolle. Zugeteilt wird in "Personen & Zugaenge", direkt in der Personenzeile: Betreuung ist eine Eigenschaft der Person, kein eigener Vorgang. Nur das Management darf zuteilen -- koennte ein Scout sich selbst Creator geben, haette er die Rechtevergabe in der Hand, die ihn begrenzen soll. Zustaendig koennen nur aktive Scouts sein, kein Admin (der sieht alles) und kein anderer Creator. Bei der Uebergabe aus der Pipeline passiert die Zuteilung von selbst: Wer jemanden gefunden hat, betreut ihn weiter. Genau darum geht es bei "Creator-Onboarding starten". Umhaengen kann das Management jederzeit. GRENZE 2: betreuen, nicht verwalten. Profile, die fuenf Bereiche und Reports wie ein Manager. ABER: - keine Zugangscodes, kein Sperren von Personen (personen.html bleibt admin-only, unveraendert) - keine management-internen Felder. Der Scout bekommt admin_notiz, plan_start und naechster_review NICHT -- die Felder fehlen in der Antwort komplett, nicht nur in der Anzeige. Eine Notiz UEBER die Betreuung gehoert nicht in die Hand dessen, der betreut. Geprueft: Ein Scout, der admin_notiz mitschickt, aendert sie nicht. Die Regel steht an EINER Stelle (betreuteIds / betreutWo / darfCreator in workspace.js) und wird von sechs Modulen benutzt. Eine Rechteregel, die an sechs Stellen steht, ist eine Rechteregel, die irgendwann an fuenf Stellen stimmt. Genau das ist beim Bauen auch passiert: workspace-calls.js hatte eine wortgleiche Kopie der Kalender-Sichtbarkeit. Erweitert wurde nur der Kalender -- Scouts sahen die Termine ihrer Creator, dieselben Termine als Call aber nicht. Die Kopie ist jetzt weg, calls.js importiert die Regel aus workspace-kalender.js. Zwei Fehler, die die Aenderung selbst erzeugt haette, vorher gefunden: - Report-Entscheidung: ein Scout haette eine Aufgabe angelegt, deren "Creator" er selbst ist -- die waere in jeder Auswertung falsch mitgelaufen. Zeigt jetzt auf einen seiner Creator. - Bereichseintrag: derselbe Fehler. Ein Scout hat gar keinen eigenen Betreuungsbereich. Ein Eintrag ohne oder mit fremder Zuordnung landet beim ersten zugeteilten Creator, nie bei einem fremden. Geprueft: Mikas Bereich bleibt bei jedem Versuch unberuehrt.	2026-08-28 11:18:56 +02:00
DogFatherGit	df9f87af0a	Workspace: Phase 2 -- LIVE, Content, Technik, Community, Schutz ... Fuenf Bereiche auf einmal, aber NICHT fuenf Module. Im Deck haben sie dieselbe Grundform: Eintraege zu einem Creator mit Art, Datum, Titel, Text und Status. Sie unterscheiden sich nur darin, welche Arten es gibt und ob eine Bewertung oder eine Dringlichkeit dazugehoert. Deshalb ein gemeinsamer Unterbau: eine Tabelle, eine Sichtbarkeitsregel, eine Pruefung, eine Ansichtsseite (bereich.html?b=live). Ein Fehler laesst sich damit an EINER Stelle beheben statt an fuenf, und ein weiterer Bereich waere ein Eintrag in BEREICHE -- kein neues Modul. Arten woertlich aus dem Deck (Seiten 7-12): live Vorbereitung / Waehrend LIVE / Auswertung + Bewertung 1-5 content Idee / Produktion / Veroeffentlicht technik Setup / Problem / Loesung / Anleitung + Dringlichkeit community Moderation / Aktion / Konflikt + Dringlichkeit schutz Richtlinie / Vorfall / Eskalation / Gelernt + Dringlichkeit Die Oberflaeche kennt die Bereiche nicht auswendig -- welche Arten und Zusatzfelder es gibt, sagt der Server in der Antwort. Geprueft, und zwar fuer alle fuenf gleichzeitig: - Sichtbarkeit: Chef sieht alles, Luna nur ihren Bereich, Mika nur seinen, Sam (Scout) gar nichts (404 -- Scouts haben mit der Creator-Betreuung nichts zu tun) - Luna legt Eintrag mit creator_id=Mika an: landet still in ihrem eigenen Bereich, Mika sieht ihn nicht - Luna auf Mikas Eintrag: 404; Luna loescht Chefs Eintrag ueber ihren Bereich: 403 (loeschen darf das Management und wer ihn schrieb -- sonst koennte ein Creator eine Notiz ueber sich verschwinden lassen) - Eintrag ueber den falschen Bereich in der Adresse ansprechen: 404 - unbekannte Art 400, Bewertung 9 (erlaubt 1-5) 400, unbekannter Bereich 404, fremde Herkunft 403 Beim Testen sahen Umlaute zunaechst zerstoert aus (efbfbd, das Unicode-Ersatzzeichen). Ursache war der curl-Aufruf: Git Bash kodiert $'\xc3\xbc' nach Locale um. Ueber den echten Weg (Browser) kommen Umlaute, ss und Gedankenstrich unveraendert an und liegen sauber in der Datenbank -- gegengeprueft auf Byte-Ebene.	2026-08-28 09:19:39 +02:00