3 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGit	39c0b4dc1f	Ein Modi sieht nur SEINE Aufgaben -- und gibt sich selbst keine ... Filipe, unmissverstaendlich und mehrfach: "die modis sollen immer nur ihre aufgaben auch sehen und nicht die von anderen, so wie bei den daten ... damit wir endlich den modis aufgaben anstaendig verteilen koennen und sie sich nicht selber aufgaben geben." DAS DREHT DIE ENTSCHEIDUNG VOM 09.09. AUSDRUECKLICH UM. Damals: "ja, sie sind untereinander ein team", damit ein Schichttausch ohne Umweg geht. Beides steht jetzt im Code nebeneinander, damit niemand spaeter die aeltere findet und fuer die gueltige haelt. VIER AENDERUNGEN: Die Sicht. Ein Modi sieht nur `a.verantwortlich_id = ich`. Was ihm ueber aufgaben_zuteilung gegeben wurde, haengt mitZugeteilten() an -- ein Pool, in dem er steht, bleibt also sichtbar, bis ihn jemand uebernimmt. Die rechte und die linke Hand behalten die Uebersicht. Das Anlegen. Im Team Dogi legt nur an, wer auch verteilen darf. In der AGENTUR bleibt es, wie es war -- dort ist eine Aufgabe eine Notiz an sich selbst, kein Auftrag von jemandem. Eine Regel, die beide Haeuser ueber einen Kamm schert, waere falsch. Der Knopf. "Neue Aufgabe" steht fuer einen Modi gar nicht mehr da. Ein Knopf, der mit 403 antwortet, ist schlimmer als keiner: Die Meldung erscheint ganz oben, und wer weiter unten steht, sieht nur, dass nichts passiert. Die Kacheln. Ein Modi sieht jetzt den Bereich "Entwicklung & Nachwuchs" mit denselben zwei Kacheln wie die Leitung -- nicht mehr zwei eigene mit anderem Namen. Zwei Namen fuer dieselbe Sache ist genau der Fehler, der am 19.09. zwei Kacheln "Chat" ergeben hat. "Talente" bleibt draussen: Dort stehen Notizen ueber Zuschauer, die nichts davon wissen. UND DIE LINKE HAND SIEHT "DEIN TEAM" NICHT MEHR (Filipes Wunsch). Abgeleitet, nicht nachgebaut: Ihre Liste ist die der rechten Hand MINUS dieser einen Kachel, erkannt am ZIEL statt am Namen -- der Name ist am 17.09. schon einmal gewandert. Gemessen: admin 30 Kacheln, hand 30, linke 29 (ohne "Dein Team"), modi 25 (mit dem Bereich, ohne Talente). Zwei Pruefungen hielten die alte Regel fest und wurden dadurch rot -- genau ihre Aufgabe. Beide umgedreht, mit der alten Entscheidung im Kommentar. pruef-zuteilung 65/0, pruef-verteilen 19/0 (war 15), pruef-aufgabenbrett 49/0.	2026-09-22 01:17:11 +02:00
DogFatherGit	b506c7f533	Die Oberflaeche dazu: Resuemee, Annehmen, Ablehnen, Bewerten ... Auftrag vom 21.09.2026, Abschnitte 1 bis 5 -- der sichtbare Teil. UEBER DEM BRETT STEHT JETZT EIN BAND, und es ist rollenabhaengig: Modi "Deine Aufgaben" -- sein persoenliches Resuemee mit offen / in Arbeit / erledigt / ueberfaellig, und darueber EIN Satz, der die Zahlen einordnet. Fuenf nackte Zahlen sind eine Tabelle, ein Satz ist eine Auskunft. DogFather, "Wer hat gerade was" -- eine Zeile je Person mit beide Haende ihren Marken. Antippen filtert das Brett auf sie, noch einmal antippen zeigt wieder alles. Ohne das zweite waere der Filter eine Falle: hinein ja, heraus nein. WELCHES BAND JEMAND BEKOMMT, entscheidet `darf_verteilen` vom Server -- aufgaben.js muss die Rollen dafuer nicht kennen. AN JEDER KARTE steht jetzt, wer sie hat und wie es bei jedem steht: Name, Zustand, bei einer Ablehnung der Grund daneben (wer "abgelehnt" liest, will als Naechstes wissen, warum), bei einer Rueckmeldung der Text dazu. Und genau die Knoepfe, die fuer DIESEN Menschen gerade gehen: Annehmen / Ablehnen, bei einem Pool "Ich uebernehme das", danach "Ich fange an" und "Fertig". Ein "Annehmen" an einer fremden Aufgabe waere ein Knopf, der mit 403 antwortet -- und die Meldung erscheint ganz oben, wo man sie bei einer Karte weiter unten gar nicht sieht. Diese Lektion stand in aufgaben.js schon einmal. DIE BEWERTUNG SIND DREI BENANNTE KNOEPFE, keine Auswahl im Dialog. Abschnitt 5 nennt drei Moeglichkeiten -- als Auswahl hiesse das: erst klicken, dann lesen, dann waehlen. Als drei Knoepfe sieht man sofort, was es gibt. Bei "Verbesserungsmoeglichkeiten" ist der Text Pflicht ("soll ein Eingabebereich erscheinen"), bei den anderen freiwillig. AN MEHRERE VERTEILEN ist ZUSAETZLICH und nicht statt dessen: Eine Person ist der haeufigste Fall und bleibt ein Klick. Wer mehr will, klappt "Noch jemanden dazunehmen" auf. Die Namen darin werden aus der Auswahl darueber ABGELEITET -- zwei Namenslisten in einer Datei, die jeder herunterlaedt, waeren eine zu viel. Die Frage "wie soll das laufen" erscheint erst ab zwei Leuten; vorher waere sie eine Entscheidung ohne Gegenstand. EIN EIGENES MODUL (zuteilung.js), weil aufgaben.js schon 1900 Zeilen hat. Die Zustandswoerter kommen vom SERVER, nicht aus einer zweiten Liste im Browser -- sonst heisst derselbe Zustand an zwei Stellen anders. ZWEI DINGE, DIE ERST DAS MESSEN GEZEIGT HAT: (1) `window.nachfragen` gibt es nicht -- der Dialog heisst `frageNach` und kennt `grund`/`grundPflicht`, aber keine Auswahl. Ich hatte eine Schnittstelle benutzt, die ich mir gemerkt statt nachgesehen hatte. Aus der Not wurde die bessere Loesung: drei Knoepfe. (2) Auf dieser Seite gibt es KEIN Suchfeld -- `#wer` in der Kopfleiste ist die Anzeige, wer angemeldet ist. Der Personenfilter wirkt deshalb unmittelbar am Brett. pruef-zuteilung: 66/0 (war 48/0) -- 18 davon am echten Bildschirm. Der Browserteil scheiterte zuerst mit `chrome-error://chromewebdata/`: crew.dogfather-universe.com steht in Chromiums eingebauter HSTS-Liste, der Browser schaltet von sich aus auf https, und der Testserver spricht http. Abschalten geht nicht (die Liste ist einkompiliert). Jetzt derselbe https-Vorbau wie in pruef-handy-teamdogi -- eine Nachbildung waere die zweite Fassung, die anders altert. Nachbarn gruen: pruef-aufgabenbrett 49/0, pruef-verteilen 16/0, pruef-css-klassen 30/0, pruef-tippziele 11/0.	2026-09-21 18:01:30 +02:00
DogFatherGit	ef0fddc724	Aufgaben an Menschen: zuteilen, annehmen, ablehnen, bewerten ... Auftrag vom 21.09.2026, Abschnitte 2 bis 5 -- der Serverteil. DREI ARTEN ZU VERTEILEN, und der Unterschied zwischen den letzten beiden ist der ganze Punkt: einzeln eine Person, sie macht es mehrere mehrere Personen, JEDE macht ihren Teil pool mehrere sehen es, EINE nimmt es -- danach ist es fuer die anderen weg, damit niemand doppelt arbeitet EINE EIGENE TABELLE, KEINE SPALTEN AN DER AUFGABE. Abschnitt 4 verlangt ausdruecklich: *"Die Aufgabe muss in der Auswertung auf die einzelnen zugewiesenen Personen aufgeteilt werden"* -- und gleichzeitig soll "die urspruengliche gemeinsame Aufgabe ihre uebergeordnete Struktur" behalten. Eine Aufgabe hat EINEN Titel und EINE Frist, aber je Mensch einen eigenen Stand, einen eigenen Grund beim Ablehnen, ein eigenes Erledigt-Datum und eine eigene Rueckmeldung. Das in Spalten zu pressen hiesse, dieselbe Aufgabe mehrfach anzulegen. `aufgaben.status` bleibt daneben unberuehrt. Zwei Ebenen, weil es zwei Fragen sind: "Wie steht die Aufgabe?" und "Wie steht sie bei IHM?" Ein einziges Feld koennte bei drei Leuten nicht gleichzeitig "angenommen" und "abgelehnt" sein. DER WICHTIGSTE EINZELNE HANDGRIFF -- und er steht nicht im Auftrag: Wer eine Aufgabe BEKOMMEN hat, sieht sie jetzt immer. Bei "mehrere" und "pool" bleibt `verantwortlich_id` leer, und die alten Sichtregeln fragen genau danach. Ohne die Erweiterung stuende eine Aufgabe im Resuemee der Leitung und waere fuer den, der sie machen soll, unsichtbar -- der unangenehmste denkbare Fehler in einem Aufgabensystem, und man sieht ihn nirgends. Die Erweiterung ist ein ODER, kein UND: Sie erweitert die Sicht, die Haustrennung darueber bleibt ein UND und wirkt weiter. WAS SONST NOCH ENTSCHIEDEN WURDE, mit Grund im Code: - Ablehnen braucht eine Begruendung (mind. 3 Zeichen). Ein leeres Nein ist fuer den, der verteilt hat, keine Information -- er muss dann nachfragen, und genau das sollte die Nachricht ersparen. - "Verbesserungsmoeglichkeiten" braucht einen Text. Ein leeres "kann besser" sagt nichts ausser, dass jemand unzufrieden war. - Bewertet wird erst, wenn jemand FERTIG ist. Eine Rueckmeldung auf etwas, das noch laeuft, ist keine Bewertung, sondern eine Einmischung. - Beim Pool wird VOR dem Schreiben gefragt, ob schon jemand zugesagt hat -- sonst nehmen zwei im selben Moment dieselbe Aufgabe und beide sehen "hat geklappt". - Wer schon geantwortet hat, behaelt seinen Stand, wenn die Aufgabe noch einmal gespeichert wird. Sonst muesste er ohne Grund erneut zusagen. - Wer nicht mehr dabei ist, faellt raus -- aber nur, solange er noch nicht geantwortet hat. Jemandem eine angenommene Aufgabe wegzunehmen, ohne dass er es erfaehrt, waere die unangenehmste Art, Arbeit zu verlieren. - "pool" mit einer Person wird "einzeln". Ein Pool aus einem Menschen ist keiner. `verantwortlich_id` bleibt und wird mitgefuehrt (einzeln = die Person, pool = der Uebernehmer, mehrere = leer): Brett, Startseite und Uebersicht gruppieren danach. Drei gewachsene Ansichten gleichzeitig umzubauen waere der groessere Eingriff -- und im haeufigsten Fall sagen beide dasselbe. KEIN CHECK an der nachgetragenen Spalte `verteilart`, mit Absicht: Ein CHECK auf einer nachgetragenen Spalte hiesse, die Tabelle neu zu bauen -- der Weg, der in diesem Haus am 11.09. und heute schon Spalten gekostet hat. Geprueft wird beim Schreiben. pruef-zuteilung.mjs, 48 Aussagen -- ein Arbeitstag durchgespielt. Ein Fehlschlag beim ersten Lauf, und er war lehrreich: "Cem hat keinen eigenen Stand" schlug fehl, weil Cem die Aufgabe gar nicht SIEHT (`null?.x` ist `undefined`, nicht `null`). Die Zusicherung konnte "sieht sie nicht" und "sieht sie ohne Stand" nicht unterscheiden -- also pruefte sie beides nicht richtig. Dass er sie nicht sieht, ist genau Abschnitt 1: *"Eine Modi darf nicht automatisch die vollstaendige Aufgabenuebersicht aller anderen Modis sehen."* Beide Faelle stehen jetzt einzeln da, mit einer Gegenprobe, dass seine Liste ueberhaupt laedt. Nachbarn gruen: pruef-verteilen 16/0, pruef-aufgabenbrett 49/0, pruef-umstellung 18/0.	2026-09-21 17:52:52 +02:00