A4: Bewerben statt selbst nehmen

Filipe, 22.09.2026: „die modis und linke hand sollen da nichts
uebernehmen koennen von aufgaben, ueberhaupt ueberall sollen die keine
aufgaben selber uebernehmen die ihnen nicht zugetragen sind. ich will
dass die sich fuer aufgaben bewerben koennen aber die rechte hand oder
dogfather muessen annehmen oder ablehnen koennen und das mit einem
kommentar als moeglichkeit sogar noch zum hinzufuegen."

ZWEI FRAGEN, DIE MAN AUSEINANDERHALTEN MUSS -- und das war der Schluessel:

    verteilen    eine Aufgabe an ANDERE geben
    entscheiden  bestimmen, wer sie am Ende macht

Sein Satz vom selben Tag („rechte hand linke hand und dogfather ...
koennen alle verteilen") widerspricht dem nicht, er beantwortet die
erste Frage. Die linke Hand verteilt, entscheidet aber nicht -- sie
bewirbt sich wie ein Modi. `entscheidetUeberAufgaben` steht neben
`darfAufgabenVerteilen`, und drei Stellen fragen ab jetzt dieselbe
Funktion.

DAS VERBOT HATTE DREI TUEREN, und die zweite und dritte waren beim
Planen nicht zu sehen:

  1. aus dem Pool „uebernehmen"  -- die offensichtliche
  2. beim Pool „annehmen"        -- dasselbe unter anderem Namen: Wer
                                    zusagt, nimmt sie den anderen weg.
                                    Bei „einzeln"/„mehrere" bleibt es
                                    erlaubt -- dort wurde sie ihm
                                    ZUGETRAGEN, und genau das Wort
                                    steht in seinem Satz.
  3. beim Verteilen sich selbst eintragen -- die linke Hand darf
                                    verteilen, haette sich also selbst
                                    nehmen koennen. Abgelehnt statt
                                    still gefiltert: Wer sich eintraegt
                                    und sich danach nicht findet, sucht
                                    den Fehler bei sich.

EIN FUND, OHNE DEN A4 GAR NICHT FUNKTIONIERT HAETTE
Die rechte Hand soll entscheiden -- und sah die Aufgabe nicht, um die
es ging. Gemessen an einer Pool-Aufgabe, die DogFather fuer zwei Modis
angelegt hat:

    DogFather    sieht sie    1 Bewerbung
    Modi         sieht sie    1 Bewerbung
    rechte Hand  SIEHT SIE NICHT (Liste leer)

Ihre Sichtregel sammelte Menschen mit einer TEAM_DOGI_ROLLE und fragte,
ob einer als Creator, Verantwortlicher oder Ersteller eingetragen ist.
Bei einer Pool-Aufgabe bleibt `verantwortlich_id` leer (das ist ihr
Sinn), und der Ersteller war DogFather -- der in dieser Liste nicht
steht. Alle drei Bedingungen liefen ins Leere.

Auf der Adresse von Team Dogi sehen die Haende jetzt alles. Das ist
zugleich sein Satz „sehen alle aufgaben". Die Haustrennung bleibt:
`sichtbar()` haengt fuer crew weiterhin `AND ohneAgentur(...)` davor.

WIE DIE BEWERBUNG GEBAUT IST
Kein zweiter Tisch, sondern ein weiterer Zustand derselben Zeile
(`beworben`). Die Frage „wie steht diese Aufgabe bei DIESEM Menschen"
wird dort schon beantwortet; eine zweite Tabelle haette zwei Wahrheiten
ueber dieselbe Beziehung.

Die Worte der Person (`grund`) und der Kommentar der Leitung
(`entscheid_text`) stehen in ZWEI Feldern. In dasselbe waere bequemer
und wuerde die Frage mit der Antwort ueberschreiben -- danach wuesste
niemand mehr, worum jemand gebeten hat. Dasselbe gilt, wenn eine
Bewerbung wegfaellt, weil jemand anders die Aufgabe bekommt: Der
Hinweis kommt in das Feld der Leitung, ihre Worte bleiben stehen.

Der Kommentar ist FREIWILLIG. Die Begruendung beim Ablehnen einer
zugeteilten Aufgabe bleibt Pflicht -- dort sagt jemand ab, der gefragt
wurde. Hier bittet jemand; ein „bitte" braucht keine Begruendung.
Filipes Wort ist „als moeglichkeit".

Die CHECK-Regel wurde ueber `checkListeErweitern` erweitert -- den Weg,
der seit dem 09.09. an einer Stelle steht, mit Sicherung vorher,
Spaltenliste aus PRAGMA und Indizes, die mitgehen.

UND EIN SATZ, DER NICHT MEHR STIMMTE
„Frei fuer 3 Leute — wer zuerst Zeit hat" war die Beschreibung des
Pools, solange sich jeder selbst bedienen durfte. Er sagt jetzt jedem,
was FUER IHN gilt.

GEPRUEFT
Neu: server/pruef-bewerbung-aufgaben.mjs, 66/0 -- die Regel selbst,
alle drei Tueren, der erlaubte Weg, die zwei Felder, das Zurueckziehen,
und ein Abschnitt am echten Bildschirm (ein Modi sieht „Ich bewerbe
mich" statt „Ich uebernehme das"; die rechte Hand sieht die Bewerbung
mit Annehmen und Ablehnen; die Bewerberin sieht KEINEN Block zum
Entscheiden -- sonst waere das Verbot einen Knopf weiter offen).

pruef-zuteilung auf die neue Regel umgestellt (sie hielt „Bea
uebernimmt sie" fest und wurde zu Recht rot) -- misst jetzt denselben
Effekt ueber den neuen Weg. Dazu gruen: pruef-aufgabenbrett,
pruef-meldungen, pruef-sicht, pruef-css-klassen.

ALTLAST, nicht von hier: pruef-rollen meldet einen Fehler an der
Kachel „Zu Team Dogi" (absolute Adresse). Mit `git stash` nachgemessen
-- vorher und nachher identisch.

Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
2026-09-22 18:55:06 +02:00
co-authored by Claude Opus 5
parent b79b75ab70
commit 43545e4acd
47 changed files with 1857 additions and 600 deletions
+97
View File
@@ -289,6 +289,48 @@ export const darfAufgabenAnlegen = (person) => {
export const darfAufgabenVerteilen = (person) =>
istLeitung(person) || istHand(person);
/* =====================================================================
WER ENTSCHEIDET, WER EINE AUFGABE MACHT (22.09.2026)
=====================================================================
Filipe: „die modis und linke hand sollen da nichts uebernehmen
koennen von aufgaben, ueberhaupt ueberall sollen die keine aufgaben
selber uebernehmen die ihnen nicht zugetragen sind. ich will dass die
sich fuer aufgaben bewerben koennen aber die rechte hand oder
dogfather muessen annehmen oder ablehnen koennen und das mit einem
kommentar als moeglichkeit sogar noch zum hinzufuegen."
DAS IST EINE ANDERE FRAGE ALS `darfAufgabenVerteilen`, und die zwei
auseinanderzuhalten ist der ganze Punkt:
verteilen -> eine Aufgabe an ANDERE geben
entscheiden -> bestimmen, wer sie am Ende macht
Die linke Hand darf verteilen (sein Wort vom selben Tag: „rechte hand
linke hand und dogfather ... koennen alle verteilen"), aber NICHT
entscheiden, ob sie selbst eine bekommt. Sie bewirbt sich wie ein
Modi, und die rechte Hand oder DogFather sagen ja oder nein.
GEMESSEN, WARUM ES NOETIG WAR: `istHand()` fasst die rechte UND die
linke Hand -- die linke konnte sich damit bisher Aufgaben aus dem
Pool selbst nehmen und sich beim Verteilen selbst eintragen.
Rolle istHand darfVerteilen (vorher)
admin false true
hand true true
linke true true <-- genau das soll weg
modi false false
DREI STELLEN HAENGEN DARAN, und alle drei fragen ab hier dieselbe
Funktion:
1. aus dem Pool uebernehmen
2. sich beim Verteilen selbst eintragen
3. ueber eine Bewerbung entscheiden
Eine Aufzaehlung der Rollen an drei Stellen waere die, bei der die
dritte beim naechsten Umbau vergessen wird. */
export const entscheidetUeberAufgaben = (person) =>
istLeitung(person) || person?.rolle === "hand";
/* ===== WER DARF EINE ROLLE AENDERN -- UND ZU WELCHER? (20.09.2026) ==
Filipe: "ich will dass ich da auch die rollen der leute wechseln kann
@@ -3510,6 +3552,49 @@ function umstellungen(d) {
checkListeErweitern(d, "aufgaben", "status", "abgebrochen",
["offen", "arbeit", "review", "erledigt", "abgebrochen"], jetztStempel);
/* DER ZUSTAND „beworben" (22.09.2026).
Eine Bewerbung ist keine neue Tabelle, sondern ein weiterer
Zustand derselben Zeile. Das ist nicht Sparsamkeit, sondern die
richtige Form: Die Frage „wie steht diese Aufgabe bei DIESEM
Menschen" wird schon hier beantwortet, und eine Bewerbung ist
genau eine Antwort darauf. Eine zweite Tabelle daneben haette
zwei Wahrheiten ueber dieselbe Beziehung -- und jede Liste,
jede Ansicht und jede Rueckmeldung muesste beide lesen.
Der Ablauf: beworben -> angenommen (die rechte Hand oder
DogFather sagt ja) oder -> abgelehnt (mit Kommentar).
`checkListeErweitern` baut die Tabelle dafuer neu -- der einzige
Weg, eine CHECK-Regel in SQLite zu aendern. Die Spaltenliste
kommt aus PRAGMA, die Indizes gehen mit, und vorher wird
gesichert. Steht seit dem 09.09. an einer Stelle, genau damit
diese Umstellung hier keine vierte Abschrift wird. */
checkListeErweitern(d, "aufgaben_zuteilung", "zustand", "beworben",
["offen", "angenommen", "arbeit", "erledigt", "abgelehnt", "beworben"],
jetztStempel);
/* WER ENTSCHIEDEN HAT, UND WAS ER DAZU GESAGT HAT.
`grund` traegt weiterhin die Worte der Person selbst (beim
Ablehnen ihre Begruendung, beim Bewerben ihr Anliegen). Der
Kommentar der Leitung ist etwas anderes und gehoert nicht in
dasselbe Feld -- sonst ueberschreibt die Antwort die Frage. */
for (const [spalte, form] of [
["entscheid_text", "TEXT"],
["entschieden_von", "INTEGER REFERENCES personen(id) ON DELETE SET NULL"],
["entschieden_am", "TEXT"],
]) {
const da = d.prepare("PRAGMA table_info(aufgaben_zuteilung)").all()
.map((z) => z.name);
if (da.includes(spalte)) continue;
try {
d.exec(`ALTER TABLE aufgaben_zuteilung ADD COLUMN ${spalte} ${form}`);
console.log(`[workspace] Spalte '${spalte}' an der Zuteilung ergaenzt.`);
} catch (f) {
console.error(`[workspace] Spalte '${spalte}':`, f?.message);
}
}
/* ---- Der sechste Bereich: "agentur" (06.09.2026) ----
Kernprinzip 04 des Konzepts lautet woertlich "Die Agentur bleibt
@@ -5841,6 +5926,18 @@ workspaceRouter.get("/workspace/api/ich", (req, res) => {
Aus DERSELBEN Funktion, die auch die Route benutzt. */
darf_verteilen: darfAufgabenVerteilen(person),
/* UND OB SIE ENTSCHEIDET, WER EINE AUFGABE MACHT (22.09.2026).
Das ist eine ANDERE Frage als `darf_verteilen`, und die
Oberflaeche braucht beide: Die linke Hand verteilt (also zeigt
ihr die Seite den Verteilen-Kasten), entscheidet aber nicht
(also sieht sie keine Annehmen/Ablehnen-Knoepfe an fremden
Bewerbungen, sondern einen Bewerben-Knopf fuer sich selbst).
Aus DERSELBEN Funktion, die auch die Wege absichern -- eine
Rollenliste im Browser waere die zweite Wahrheit, die beim
naechsten Umbau auseinanderlaeuft. */
darf_entscheiden: entscheidetUeberAufgaben(person),
/* Damit die Oberflaeche den Knopf gar nicht erst anbietet -- ein
Knopf, der mit 403 antwortet, ist schlimmer als keiner. */
darf_aufgaben_anlegen: darfAufgabenAnlegen(person),