So wird bei perinco nicht gerechnet: die Summe "Gewichtet" aenderte sich beim
Schieben der Abschlusswahrscheinlichkeit und behauptete damit eine Groesse, die
es im Haus nicht gibt.
Weg sind die Kennzahl ueber der Liste, die Spalte samt Sortierung, die zweite
Zahl in der Vorschau des Formulars und weightedVolume() selbst. Die
Wahrscheinlichkeit bleibt an der Opportunity - Schieberegler im Formular, Prozent
in Liste und Pipeline-Karte; sie geht nur in keine Summe mehr ein.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die Liste zeigte die zurueckgefallene Bewerbung, der Zaehler am Menue nicht: er
filterte weiter auf "nie uebernommen". Genau der Fehler, den zwei Kopien
derselben Regel machen.
Fristen und Bedingungen stehen jetzt in server/src/acquisitionRules.js und
werden von der Liste, den Zaehlern, dem Aufraeumlauf und der Menuezahl
gemeinsam benutzt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Wer eine Opportunity loescht, hat bisher auch die Bewerbung dahinter verloren:
aus der Akquise war sie mit der Uebernahme heraus, und die Opportunity gab es
nicht mehr. Der Eintrag stand nirgends.
Jetzt taucht er im Archiv auf - abgeleitet, nicht gespeichert: `converted_at`
bleibt stehen, sichtbar wird der Eintrag, solange seine Opportunity im
Papierkorb liegt oder endgueltig weg ist. Wird sie zurueckgeholt, verschwindet
der Eintrag von selbst wieder. Es gibt damit keinen Zustand, der nachgezogen
werden muesste und auseinanderlaufen kann.
Die Regel steht als IS_OPEN an einer Stelle und gilt fuer Liste, Zaehler und den
Aufraeumlauf: ein Rueckfaeller altert wie jeder andere Eintrag nach 90 Tagen
heraus, und seine Anzahl wird vorher in den Verlauf gesichert.
Ausserdem:
- Bearbeiten und erneutes Uebernehmen sind wieder erlaubt, sobald die
Opportunity weg ist. Gesperrt bleibt der Eintrag nur, solange sie lebt - dort
wird dann gepflegt.
- Der Eingang zeigt weiter nur, was nie uebernommen wurde.
- Die Zeile traegt ein Kennzeichen ("Opportunity im Papierkorb" bzw.
"Opportunity geloescht"), sonst stuende sie unerklaerlich im Archiv.
- Im Dashboard zaehlt eine Wandlung nur mit lebender Opportunity. Wird sie
geloescht, faellt die Bewerbung zurueck - dann soll die Quote nicht behaupten,
aus ihr sei eine Opportunity geworden.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Zwei Sachen, die zusammen wie ein Rechenfehler aussahen:
- Bei der Einteilung "Tag" baute die Achse ihre Schluessel mit toISOString().
Das rechnet nach UTC und liefert fuer den lokalen Tagesanfang in Zeitzonen
oestlich von Greenwich den Vortag - jede Saeule fiel neben die Achse und das
Diagramm blieb leer, obwohl die Kennzahlen Werte zeigten. Die Schluessel kommen
jetzt aus den Ortsdatumsteilen. Monat, Quartal und Jahr waren nie betroffen,
die haben ihre Schluessel schon so gebaut.
- Die Kennzahl "Bewerbungen" zaehlt alle Akquise-Eintraege des Zeitraums, auch
die, aus denen eine Opportunity geworden ist. Die stehen nicht mehr in der
Akquise-Liste, also ist die Zahl regelmaessig hoeher als die Liste lang ist.
Das stand nirgends: jetzt sagt die Fussnote der Kachel, wie viele uebernommen
wurden, und unter den Kacheln steht ein Satz dazu.
Dazu passen bei 30 Tagen jetzt alle Abschnitte nebeneinander (schmalere
Spalten), und passt es doch nicht, zeigt das Diagramm das Ende des Zeitraums -
die aktuellen Tage stehen rechts und interessieren.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Erster Menuepunkt und Startansicht; das Logo oben links fuehrt dorthin zurueck.
Vier Kennzahlen (Bewerbungen, daraus Opportunities samt Quote, gewonnene
Projekte, aktuell beim Kunden), ein Saeulendiagramm mit denselben drei Reihen
ueber der Zeit, die Bewerbungen je Berater, die naechsten Termine und alle
Opportunities in Kundenvorstellung bzw. Interview Kunde. Zeitraum ueber vier
Vorgaben oder frei, Einteilung nach Tag, Monat, Quartal oder Jahr.
Bewerbung heisst dabei: ein Eintrag in der Akquise - jeder Eintrag bedeutet, dass
ein Profil raus ist (so vom Nutzer festgelegt).
Zwei Dinge dafuer am Datenmodell:
- crm_opportunities.won_at haelt den Zeitpunkt des Wechsels nach "Beauftragt".
Die Phase allein sagt nur, wie es jetzt steht, nicht wann es passiert ist.
Beim Wechsel heraus wird das Datum geleert, sonst zaehlt das Dashboard einen
Gewinn, den es nicht gibt.
- Die Akquise loescht nach 90 Tagen - damit waere jede Jahresauswertung falsch.
Der Aufraeumlauf sichert deshalb vorher Tag, Berater und Anzahl in
crm_acquisition_history, in derselben Transaktion wie das Loeschen. Gesichert
wird nur, was verschwindet; die Auswertung addiert beide Quellen und kann sich
damit nicht ueberschneiden. Projektdaten sind nach dem Loeschen weiterhin weg.
Termine und die Phasenlisten kommen nicht aus einem eigenen Endpunkt: Termine und
Opportunities laedt die App ohnehin komplett, das Dashboard filtert sie selbst.
Diagramme von Hand (SVG-freie Balken plus Tailwind-Uebergaenge) statt einer
Bibliothek - drei Darstellungen rechtfertigen keine weitere Abhaengigkeit, und so
kommen die Farben aus denselben Tokens wie der Rest. Die Zahlen laufen hoch, die
Saeulen wachsen; wer Bewegung im System abgeschaltet hat, bekommt sofort den
Endwert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Drei Dinge:
- Die Phasen sind jetzt die des Vermittlungsprozesses: Neu, Beworben,
Erstgespraech Berater, Kundenvorstellung, Interview Kunde, Zusage, Beauftragt,
Absage. Offen ist alles bis einschliesslich Zusage - dort ist der Einsatz
bestaetigt, die Beauftragung steht aber noch aus. migrateOpportunityStages()
stellt bestehende Datenbanken um und setzt alle vorhandenen Opportunities auf
"Neu": in welcher der neuen Phasen ein Projekt steckt, sagt der alte Trichter
nicht (so mit dem Nutzer entschieden).
Der Datenbankwert heisst 'Erstgespraech Berater' ohne Umlaut - Projektkonvention
fuer Datenbankwerte. Angezeigt wird er ueber STAGE_LABELS; dazu gibt es
STAGE_HINTS mit der Erlaeuterung je Phase als Titelhinweis an Auswahl, Badge
und Spaltenkopf.
- Kanban ist die erste Ansicht der Opportunities. Die Pipeline ist die
Arbeitsansicht, Kachel und Liste sind zum Nachschauen.
- Hinter "Archiv", beiden "Papierkorb"-Punkten und "Unpassend" steht die Anzahl,
wie schon bei "Aus Mails". Die Zahlen kommen aus einem eigenen Endpunkt
(/api/badges), weil sie alle ins Menue gehoeren und zusammen kommen sollen;
Inhalte laedt weiter jede Ansicht selbst. Der Scanner liegt in einer eigenen
Datenbank und kann fehlen - sein Zaehler ist dann null und die Leiste zeigt
dort einfach keine Zahl. Der Aufruf haengt bewusst hinter den Daten und nicht
im Promise.all: faellt er aus, bleibt das Menue ohne Zahlen statt die Ansicht
mit einem Fehler.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Das Loeschsymbol gab es in der Kachelansicht schon, es war aber bis zum
Ueberfahren durchsichtig - ein Knopf, den man nur findet, wenn man ihn kennt.
Jetzt ist er sichtbar, in der Liste ebenso, und die Pipeline-Karte hat ihn
ueberhaupt zum ersten Mal.
Geloescht wird nicht mehr endgueltig: DELETE setzt deleted_at, die Zeile bleibt.
An einer Opportunity haengen Ansprechpartner, Verlauf und Mailzuordnungen, und
ein Fehlklick soll das nicht kosten. Der Papierkorb ist ein Unterpunkt unter
Opportunities und zeigt, wann und von wem geloescht wurde und wie lange der
Eintrag noch liegt. Zurueckholen darf, wer auch loeschen darf; das Leeren jeder
Angemeldete - was dort liegt, hat schon jemand mit den noetigen Rechten
weggeworfen. Beides fragt vorher nach.
Nach 90 Tagen raeumt das Backend selbst auf, beim Abruf der Liste und hoechstens
einmal pro Stunde je Prozess - dasselbe Muster wie in der Akquise. Ein eigener
Zeitplan waere eine weitere Stelle, die ausfallen kann, und die Abfragen filtern
Faelliges ohnehin heraus.
Im Papierkorb liegende Opportunities sind aus allen Listen, Summen und
Zuordnungsdialogen heraus und lassen sich nicht bearbeiten (409) - erst
zurueckholen, dann aendern.
Nebenbei: der Header bekommt seinen Titel jetzt ueber viewTitle(). Der
Ansichtsname musste eindeutig sein ("Opportunity-Papierkorb", weil die Mails
schon einen Papierkorb haben), angezeigt wird beides als "Papierkorb".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
In der Regel traegt jeder seine eigenen Funde ein - das Feld stand trotzdem bei
jedem Projekt auf leer. Vorbelegt ist jetzt der angemeldete Benutzer; wer fuer
jemand anderen eintraegt, waehlt ihn aus der Liste.
Der eigene Name steht dabei immer zur Auswahl (OptionSelect.alwaysOffer), auch
wenn ihn niemand in den Einstellungen gepflegt hat: sonst muesste sich jeder
erst selbst in die Liste eintragen, bevor er ein Projekt erfassen kann. Steht er
schon in der Liste, gilt deren Schreibweise - sonst stuenden "Markus" und
"Markus Meier" als zwei Namen in derselben Spalte.
Beim Bearbeiten bleibt der gespeicherte Name stehen, sonst wuerde ein Eintrag
beim Oeffnen den Finder wechseln.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Das Dropdown fiel dem Feld zur Last: neue Vermittler tauchen zu oft auf, als
dass das Eintragen an einer gepflegten Liste haengen sollte. Anbieter ist wieder
ein Textfeld, jetzt mit Vorschlagsliste aus den bisherigen Eintraegen - der
zuletzt benutzte zuerst.
In den Einstellungen bleiben die drei Listen "Von", "Kanal" und "Berater".
dropProviderOptions() nimmt 'provider' aus dem ENUM der Optionstabelle und
loescht die dort gepflegten Werte; die Anbieter der Akquise-Eintraege bleiben
unberuehrt, sie stehen als Text in crm_acquisitions.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"Von", "Anbieter", "Kanal" und "Berater" sind Dropdowns. Ihre Inhalte stehen in
crm_acquisition_options und werden im neuen Reiter Einstellungen -> Akquise
gepflegt. Freitext hat aus "Hays", "hays" und "Hays AG" drei Anbieter gemacht;
der Unique-Schluessel greift ueber die Kollation auch bei abweichender
Gross-/Kleinschreibung.
Eine Tabelle mit Feldkennzeichen statt vier Tabellen: die Felder verhalten sich
gleich, also ist jede weitere Liste ein Wert im ENUM statt einer neuen Route und
einer neuen Oberflaeche.
Zwei Entscheidungen dabei:
- Pflegen darf jeder Angemeldete, nicht nur ein Administrator. Eine Liste, die
nur ein Admin ergaenzen kann, blockiert die Eingabe genau dann, wenn ein neuer
Anbieter auftaucht.
- Die Eintraege halten den Text, keinen Fremdschluessel. Umbenennen zieht sie
darum ausdruecklich mit (in einer Transaktion), Loeschen nicht: eine Liste
aufzuraeumen darf keine Daten aendern. Ein Wert, der nicht mehr in der Liste
steht, wird im Dropdown weiter angeboten und als solcher gekennzeichnet -
sonst wuerde das Bearbeiten eines alten Eintrags ihn stillschweigend
ueberschreiben.
Das Backend prueft beim Speichern eines Eintrags nur noch die Laenge und nicht
mehr die Zugehoerigkeit zur Liste - aus demselben Grund.
Dazu: die Felder der Akquise-Eingabe sind abgesetzt (getoente Flaeche,
deutlicherer Rahmen, beim Hineinklicken weiss). Auf der weissen Karte gingen sie
unter, und im Formular stehen bis zu fuenfzehn davon nebeneinander.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Neuer Menuepunkt ueber den Opportunities, mit dem Unterpunkt "Archiv". Die
Liste traegt genau die Spalten, die beim Durchgehen zaehlen: Datum, Von,
Anbieter, Kanal, Projekttitel, Berater, ein Knopf fuer die Uebernahme und die
Symbole fuer Bearbeiten und Loeschen.
Eingabe steht ueber der Liste und ist bewusst kein Dialog - Projekte kommen in
Serie herein. Nach dem Eintragen bleiben Datum, Anbieter, Kanal und Berater
stehen, damit drei Projekte aus einer Mail nicht dreimal dieselben Angaben
kosten. Von, Anbieter und Berater schlagen frueher benutzte Werte vor. Was in
der Liste keine Spalte hat, aber in der Opportunity vorkommt (Endkunde,
Beschreibung, Tagessatz, Laufzeit, Projektpreis, Zeitraum, naechster Schritt,
Notizen), klappt darunter auf.
Eingang, Archiv und Loeschung ergeben sich aus dem Funddatum - 14 bzw. 90 Tage -
und aus converted_at. Es gibt keine Zustandsspalte, die ein Job pflegen muesste
und die von der Wirklichkeit abweichen kann. Der Loeschlauf raeumt beim Abruf
der Liste, hoechstens einmal pro Stunde; die Abfragen filtern Faelliges ohnehin
heraus.
Die Uebernahme legt Opportunity und Merker in einer Transaktion an. Anbieter,
Von, Kanal, Berater und Link haben in der Opportunity kein Feld und wandern als
Herkunftsvermerk in die Notizen.
Der Titel wird nur dann zum Link, wenn eine http(s)-Adresse hinterlegt ist:
"hays.de/projekt/1" ergaenzt das Backend zu https://, und die Anzeige laesst
nichts anderes durch als http und https.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Drei Aenderungen aus dem Alltagsgebrauch:
- Der Kalender heisst jetzt "Interviews" - dafuer wird er benutzt. Der Wert in
ViewState wandert mit, damit Menue und Kopfzeile nicht auseinanderlaufen.
Sichtbare Reste ("Kalenderfarbe") heissen jetzt Terminfarbe.
- Mails haben einen Papierkorb, der unter dem Menuepunkt aufklappt. Loeschen
heisst dabei ausschliesslich: im CRM. Im Postfach crm@perinco.de bleibt die
Mail unberuehrt - Schreibrechte darauf hat die Anwendung nicht. Damit der
Delta-Abgleich geloeschte Mails nicht wieder einliest, bleibt nach dem Leeren
eine leere Zeile als Merker stehen (crm_purged); runMailSync() ueberspringt
alles, was im CRM geloescht ist. Zurueckholen und Leeren darf jeder
Angemeldete, Leeren nach einer Warnung.
- Der Kontaktstatus (Neu .. Verloren) wird zur Kontaktart: Recruiter, Partner,
Endkunde. Die Spalte heisst jetzt kind, weil "Status" das Feld falsch
benannte. migrateLeadKind() stellt bestehende Datenbanken um und setzt alle
vorhandenen Kontakte auf Recruiter - welche Art jemand ist, sagt der alte
Status nicht (so mit dem Nutzer entschieden).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Drei Dinge, die im Alltag gefehlt haben:
- Projektdaten kennen jetzt einen Projektpreis. Ist er gesetzt, gilt er als
Volumen statt Tagessatz x Laufzeit - Festpreisprojekte mussten bisher
ausgerechnet und in den Tagessatz gefaelscht werden.
- Dialoge schliessen auch per Klick in den Hintergrund, nicht nur ueber das X.
Escape trifft dabei nur den obersten Dialog; eine Textmarkierung, die im
Dialog beginnt und daneben endet, schliesst nichts.
- Fehlt ein Ansprechpartner noch im CRM, oeffnet "Neuer Kontakt..." in der
Opportunity denselben Dialog wie unter Kontakte. Der frische Kontakt haengt
danach sofort als Ansprechpartner dran, ohne die Opportunity zu verlassen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Knoten laufen auf eigenen Lissajous-Bahnen, Linien folgen den Knoten.
Positionen werden per requestAnimationFrame direkt am DOM gesetzt, damit
React nicht pro Frame neu rendert. Bei prefers-reduced-motion bleibt das
Muster statisch.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Am Kontakt gibt es unter der E-Mail-Adresse das Kästchen "Einverständnis
für Mails". Ohne Adresse ist es gesperrt. Der Zeitpunkt wird in
`mail_consent_at` mitgeschrieben und im Kontakt angezeigt: bei einer
Beschwerde ist nicht die Frage, ob ein Einverständnis vorliegt, sondern
seit wann. Beim Widerruf wird er geleert; ein erneutes Speichern
verschiebt ihn nicht.
Der Knopf "Mailingliste erstellen" in der Kontaktleiste sammelt alle
Adressen mit Haken, durch Komma getrennt, mit Zähler am Knopf. Rechts im
Feld ein Kopiersymbol (Zwischenablage, mit Fallback für Browser ohne die
Schnittstelle) und ein Mailsymbol.
Zum Mailsymbol zwei Entscheidungen:
- Die Adressen gehen ins BCC, nicht ins An-Feld. Im An-Feld sähe jeder
Empfänger die vollständige Kundenliste.
- Windows gibt an das Mailprogramm nur rund 2000 Zeichen weiter. Ab 1900
Zeichen ist das Symbol deshalb gesperrt und der Dialog erklärt es -
sonst wäre die Empfängerliste unbemerkt abgeschnitten.
Nur für richtige Kontakte: Der Vorbereich "Aus Mails" hat das Kästchen
nicht, und beim Übernehmen wird der Haken nicht mitgesetzt - dass jemand
eine Mail geschrieben hat, ist keine Einwilligung in Werbung. Das Backend
weist ein `mail_consent` für Einträge mit `mail_pool = 1` ab.
Sichtbar ohne Öffnen: grünes Briefsymbol in der Kachel, Häkchen hinter der
Adresse in der Liste.
Geprüft im Browser gegen das Stub-Backend: Haken setzen und widerrufen,
Zähler, Komma-Liste, Zwischenablage, mailto mit BCC, kein Kästchen im
Vorbereich (15 Prüfungen).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`last_scan_at` hielt das ENDE des Laufs fest. Der Scheduler rechnet die
Fälligkeit aber von diesem Wert aus, also kam die Laufzeit von drei bis
vier Minuten jedes Mal obendrauf: bei Einstellung 15 Minuten lagen die
Läufe 19 Minuten auseinander.
Gemessen heute früh, unsere Instanz gegen das Original:
wir: 07:00 07:19 07:38 07:57 08:16 → 19 Min
Original: 07:00 07:16 07:31 07:47 08:03 → 15-16 Min
Über das Fenster 07-22 Uhr sind das rund 47 statt 58 Durchgänge pro Tag.
Die Trefferliste der Börsen zeigt nur die neuesten Projekte, jeder
ausgelassene Durchgang kostet deshalb echte Funde.
Jetzt wird der Startzeitpunkt gespeichert. Das `finally` bleibt, damit
sich ein gescheiterter Lauf nicht sofort wiederholt; dauert ein Lauf
länger als das Intervall, ist der nächste sofort fällig - die Sperre aus
demselben Commit verhindert die Überlappung.
Kein Rückschritt zum vorherigen Fehler (e58b94f): der Zeitstempel liegt
weiterhin in der Datenbank und trägt den Zeitplan über Neustarts.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
16 Screenshots in docs/bilder/, eingebunden in die Benutzeranleitung und als
Aufmacher im README: Opportunities (Kachel und Pipeline), Kalender (Monat
und Woche), Kontakte (Kachel, Netzwerk, Dialog), Aus Mails samt
Feldauswahl, Postfach mit Zuordnungen, Kontakt-Vorschläge, Scanner
(Dashboard, Suchagenten, Börsen-Konten), Einstellungen und eine Ansicht im
dunklen Design.
Aufgenommen mit Playwright gegen ein Stub-Backend mit **erfundenen**
Beispieldaten, nicht gegen die Live-Instanz: echte Kontakt- und
Umsatzdaten haben in Screenshots im Repo-Verlauf nichts zu suchen, und
erfundene Daten lassen sich jederzeit identisch neu erzeugen. Ein Hinweis
darauf steht in der Anleitung und im README.
Feste Fenstergröße 1440x900 ohne Skalierung, PNG, zusammen 2,0 MB - lesbar,
aber klein genug fürs Repo. Die Pipeline ist mit 1760 Breite aufgenommen,
weil sie sechs Spalten hat.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Dateibaum im README und in 05/08, die Kommentare hinter # in den
Beispielbefehlen und die Beschriftungen in Mermaid-Sequenzdiagrammen sind
Lesetext, stehen aber in Codeblöcken - die erste Runde hat sie deshalb
übersprungen.
Die Befehle selbst und alle Bezeichner bleiben unverändert: ersetzt wurde
nur hinter "# ", hinter den zwei Leerzeichen des Dateibaums und hinter
": " in Mermaid-Nachrichten. ER-Labels wie bewertet_fuer sind Bezeichner
und bleiben, "systemctl daemon-reload" ebenfalls.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
893 Stellen in Fliesstext, Tabellen und Mermaid-Beschriftungen. Dazu die
sichtbaren ss-Fälle (ausschließlich, groß, außen, schließt, heißt,
draußen, weiße, anstoßen, Straße).
Nicht angetastet, damit die Doku weiter beschreibt, was wirklich in der
Datenbank steht:
- Codeblöcke und Code-Spans - dort stehen Bezeichner, SQL, Enum-Werte
und Dateinamen: `mail_pool`, `'uebernommen'`, `extract.js`
- in Mermaid nur der Text in Anführungszeichen; Knotennamen, Pfeile und
Werte wie source = 'Mail' bleiben, wie sie sind
- `empfaenger` im ER-Diagramm von crm_mail_contact_candidates: die
Aufzählung dort nennt die Datenbankwerte, nicht die Anzeige
Die Menü-Skizze in der Benutzeranleitung zeigt jetzt die aufgeklappten
Kontakte mit "Aus Mails" samt Zähler.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Menüs, Dialoge, Schaltflächen, Platzhalter, Hinweise und die
Fehlermeldungen der API standen in Ersatzschreibweise (oe/ae/ue). Sie
erscheinen als Toast oder Beschriftung direkt in der Oberfläche und
gehören damit richtig geschrieben; sechs sichtbare Texte mit ss statt ß
sind gleich mit erledigt ("Schließen", "Straße", "zu groß").
Unangetastet bleibt bewusst:
- Kommentare im Quelltext - die sind durchgängig ASCII, und der Diff wäre
dreimal so groß ohne Nutzen für den Benutzer
- Protokollzeilen (console.*) - die landen im journal, nicht in der App
- Datenbankwerte und interne Kennungen: 'uebernommen', 'empfaenger',
'vorschlaege', 'laeuft-bereits' stecken in Enums, SQL und
Zustandsvergleichen. Ein Umlaut darin hätte still falsche Ergebnisse
geliefert
- server/src/mail/extract.js - die Muster decken absichtlich beide
Schreibweisen ab: /gr(ü|ue)(ß|ss)e/
- scanner/utils/crypto.js - der Ersatzschlüssel darf sich nicht ändern,
sonst sind gespeicherte Portal-Passwörter nicht mehr lesbar
Geprüft mit einem Rundgang durch die Ansichten und Dialoge: sichtbarer
Text plus title/aria-label/placeholder enthalten keine
Ersatzschreibweisen mehr.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Postfachabgleich hat gefundene Personen bisher direkt in den
Kontaktbestand geschrieben. Damit wächst eine gepflegte Liste ungefragt
mit jeder Adresse aus jeder Mail - genau daran ist das Altsystem
gescheitert.
Funde landen jetzt in einem Vorbereich (crm_leads.mail_pool = 1), der als
Unterpunkt "Aus Mails" unter dem Menüpunkt Kontakte aufklappt. Der
Kontaktbestand bleibt unberührt, bis dort jemand entscheidet; in
Opportunities, Kalender und Netzwerk tauchen die Funde nicht auf.
Eine Spalte statt einer zweiten Tabelle, weil crm_mail_links und
crm_mail_contact_candidates per Fremdschlüssel auf crm_leads zeigen - so
behält der Vorbereich seine Mailbezüge.
Übernehmen kennt zwei Wege:
- neue Person: Kopie mit mail_pool = 0, die Mailverknüpfungen wandern mit
- Dublette (Adresse, sonst voller Name): gold markiert, abweichende
Felder mit altem und neuem Wert; die Feldauswahl schreibt sie in den
vorhandenen Kontakt. Vorausgewählt sind nur Lücken - ein Wert aus einer
alten Signatur soll nichts Gepflegtes stillschweigend ersetzen.
db.js verschiebt beim ersten Start die vorhandenen Kontakte mit
source = 'Mail' in den Vorbereich, einmalig über den Merker
leads_mail_pool_migrated in crm_settings.
Die Sidebar-Gruppe ist dabei generisch geworden (MenuGroup) - Kontakte
und Scanner benutzen jetzt denselben Code.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Lehnt Graph den Serverfilter ab, laeuft der Erstabgleich ohne Filter - und zieht
sich dann ueber mehrere Laeufe. Der Merker dafuer galt nur im ersten Lauf, in
allen folgenden waere der Rest des Postfachs trotz eingestellter Grenze
hereingekommen. Die Grenze wird jetzt immer geprueft, und zwar nur fuer noch
unbekannte Mails: eine bereits gespiegelte Mail soll auch dann aktualisiert
werden, wenn sie aus dem Zeitfenster gelaufen ist.
insertCandidates() gibt die Zeilen jetzt in der Form der Datenbank zurueck. Die
Umformung an der Aufrufstelle waere bei jedem neuen Feld still auseinandergelaufen
und haette es bei der automatischen Uebernahme verloren.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Spiegelt das Vertriebspostfach ueber Microsoft Graph ins CRM. Aus jeder Mail
entstehen Kontakt-Vorschlaege, und jede Mail laesst sich an Opportunities und
Kontakte haengen.
Uebernommen ist die Idee aus dem Altsystem KeepTrack, nicht die Umsetzung:
- Delta Query statt "$filter=isRead eq false" mit anschliessendem PATCH. Damit
genuegt die Anwendungsberechtigung Mail.Read, es braucht keinen Schreibzugriff
auf das Postfach, und eine vorher in Outlook geoeffnete Mail geht nicht
verloren. Der Fortschritt liegt als delta_link in der Datenbank und ueberlebt
Neustarts; ein Lauf ist gedeckelt und fortsetzbar.
- Tenant- und Client-ID kommen aus der .env, nicht aus dem Browser. Im
Altsystem konnte jeder Angemeldete das Server-Secret gegen einen fremden
Tenant verwenden.
- Kontaktdaten werden aus den Graph-Feldern und der Signatur gelesen, ohne
Sprachmodell. Mailinhalte verlassen den Server nicht.
- Ein Vorschlag ohne E-Mail-Adresse wird nicht mit einer erfundenen Adresse
angelegt, sondern bleibt zur Durchsicht liegen. Ist die Adresse schon als
Kontakt vorhanden, werden nur leere Felder ergaenzt.
- Mails haengen als eigene Verknuepfung an Opportunity und Kontakt, nicht als
Text im Notizfeld - loesbar und mehrfach moeglich.
- Fremdes Mail-HTML wird serverseitig entschaerft und in einem iframe mit
sandbox="" gezeigt. Externe Bilder sind per CSP gesperrt, damit das Oeffnen
dem Absender nichts meldet.
- Der Verbindungstest prueft Anmeldung und tatsaechlichen Postfachzugriff und
benennt den wahrscheinlichen Grund. Der alte Test holte nur ein Token.
Fehlen die MS_*-Werte, startet das CRM normal; die Einstellungen nennen die
fehlende Variable. Neue Tabellen: crm_mail_messages, crm_mail_links,
crm_mail_contact_candidates, crm_mail_sync_state, crm_settings.
Uebernommene Kontakte tragen source = 'Mail'; die Kontaktliste hat dafuer einen
Herkunftsfilter.
Nicht enthalten: Senden, Antworten, Weiterleiten, Anhaenge und die automatische
Zuordnung zu Opportunities.
npm test im Verzeichnis server prueft Kontaktextraktion und Graph-Client
(47 Pruefungen, ohne Framework und ohne Datenbank).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Im Monatsraster wechselt ein gezogener Termin den Tag und behaelt seine
Uhrzeit; in Woche und Tag rastet er auf 15 Minuten ein. Der Greifpunkt
wandert mit, die Dauer bleibt erhalten, und eine gestrichelte Linie zeigt
die neue Startzeit vorab an.
Die Anzeige springt sofort ans Ziel (pendingMoves) und faellt zurueck,
wenn der Server den PATCH ablehnt. Ziehen darf nur, wer den Termin auch
aendern darf - das prueft der Server ohnehin erneut.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die bisherige Dokumentation beschrieb die Architektur, half aber niemandem, der
die Anwendung zum ersten Mal oeffnet. Dazu jetzt vier Kapitel:
- 07 Anleitung fuer Benutzer: was die Anwendung tut, jeder Bereich Schritt fuer
Schritt, warum der Signalton nur im Dashboard klingelt, was Loeschen eines
Suchagenten mitnimmt
- 08 Anleitung fuer Entwickler: einrichten, pruefen, Feld/Menuepunkt/Reiter/
Endpunkt hinzufuegen, dazu eine Tabelle der Fallen, die real Zeit gekostet
haben (Routen-Reihenfolge, FormData, Leerzeichen in Pfaden, Zeitstempel
koennen nur vorziehen, Kaskaden beim Loeschen)
- 09 Quellcode-Referenz: jede Datei mit ihren Exporten und den Zusagen, auf die
sich der Rest verlaesst
- 10 Glossar: Agent, Match, Lead, Opportunity und die Statuswerte der Datenbank
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die Sperrfrist nach dem Start begann bei jedem Neustart von vorn. Zwei
Deployments im Abstand von zehn Minuten haben den faelligen Suchlauf damit
zweimal um eine halbe Stunde verschoben - er fand nie statt. Wer oefter als
alle SCANNER_SCHEDULER_OFFSET Minuten deployt, hat einen Scanner, der
automatisch nie sucht.
Der Zeitpunkt des letzten Laufs liegt jetzt in settings.last_scan_at, von der
Pipeline geschrieben (auch nach einem Abbruch, damit sich ein gescheiterter
Lauf nicht sofort wiederholt). Der Versatz greift nur noch, solange dort nichts
steht - also beim allerersten Start dieser Instanz, wo er gebraucht wird.
Der Scheduler liest den Wert zusaetzlich in jedem Tick: ein manueller Scan aus
der Oberflaeche schreibt ihn, weiss aber nichts von der Variablen im Scheduler.
Ohne den Abgleich konnte der Scheduler direkt hinter einem manuellen Lauf noch
einmal losziehen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der eigenstaendige Projekt Scanner zieht komplett ins CRM ein und laeuft
parallel zur bestehenden App weiter - jede geteilte Ressource ist verdoppelt
statt geteilt, damit die alte Installation unberuehrt bleibt:
- eigene Datenbank perinco_scanner, legt sich beim Start selbst an
- eigener SCANNER_ENCRYPTION_KEY, eigenes Upload-Verzeichnis
- eigener Scheduler mit Zeitversatz, damit nicht beide Instanzen gleichzeitig
mit denselben Portal-Cookies scrapen (Rate-Limits, CAPTCHA, doppelter RAM)
- Sperre gegen ueberlappende Laeufe: Scheduler und "Jetzt scannen" teilen sie,
ein zweiter Aufruf bekommt 409 statt doppelter OpenAI-Kosten
Backend unter /api/scanner hinter der CRM-Anmeldung; die HTTP-Basic-Auth des
Originals entfaellt. CV-PDFs kommen als Stream mit Token statt aus einem
statischen Verzeichnis. Bestandsdaten holt "npm run scanner:import" aus der
alten Datenbank, ohne sie zu veraendern.
Oberflaeche in Tailwind und CI-Farben neu gebaut: Menuepunkt Scanner mit
aufklappbaren Unterpunkten, Einstellungen als eigener Reiter.
Whisper hat keinen eigenen Menuepunkt mehr, sondern ist ein Reiter in den
Einstellungen. Damit diese Geraeteeinstellung jeder Rolle offensteht, sind die
Einstellungen jetzt fuer alle sichtbar - welche Reiter erscheinen, entscheidet
die Rolle.
Ausserdem: kein festes Admin-Passwort mehr im Quelltext, playwright exakt auf
1.60.0 gepinnt (nutzt den vorhandenen Chromium-Build des Servers), technische
Dokumentation mit Funktionszeichnungen unter docs/.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
