Der Scanner liegt in einer eigenen Datenbank (perinco_scanner); die
KI-Suche las nur die crm_*-Tabellen und fand deshalb nichts zum Scanner.
Treffer ab Anzeigeschwelle gehen jetzt als scanner_matches mit, Refs vom
Typ "scanner" fuehren in die Scanner-Ansicht.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Die Berater haben keinen Zugang zum CRM. Die Mail verlinkt nur noch die
Ausschreibung, falls hinterlegt; der Hinweis auf die Einstellungen in der
Fusszeile entfaellt ebenso. CRM_PUBLIC_URL wird nicht mehr gebraucht.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Betreff "Du wurdest beworben: <Titel>", Text "wir haben dich auf folgendes
Projekt beworben", Link zum Projekt als ausgeschriebene Zeile in der
Tabelle statt versteckt hinter "Zur Ausschreibung".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Wird in der Akquise ein Projekt mit Berater angelegt (oder ein Berater
beim Bearbeiten hinzugefuegt), bekommt er eine Mail ueber Graph sendMail
aus crm@perinco.de; Reply-To ist der eintragende Benutzer. Je Berater
abschaltbar unter Einstellungen -> Akquise (Spalte notify, Vorgabe an).
Versand laeuft nach der Antwort und kippt das Speichern nie.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Neue Spalte crm_acquisition_options.email, pflegbar unter
Einstellungen -> Akquise direkt in der Berater-Zeile. Beim ersten Start
werden vorhandene Berater einmalig mit vorname.nachname@perinco.de
vorbelegt (Merker consultant_email_seeded); Namen ohne Nachnamen bleiben leer.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Neue Spalten stage_changed_at/stage_changed_by, gesetzt nur bei echtem
Phasenwechsel per PATCH. Der Dialog zeigt unter "Angelegt von" die Zeile
"Verschoben von ... am ... um ... in ...".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
isReasoningModel() kannte nur gpt-5. gpt-6-luna bekam deshalb
temperature 0.1 und OpenAI lehnte jeden Aufruf mit 400 ab ("Only the
default (1) value is supported"). Jetzt zaehlt jede Generation ab 5.
Vergleich gpt-4o-mini gegen gpt-6-luna in docs/14-ki.md.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Das JSON-Beispiel im alten Prompt ("Deutsch nur auf B2-Niveau") hat das
Modell in rund 1600 Cons uebernommen, und knappe Beschreibungen (Freelancermap
meist nur Titel) wurden pauschal niedrig bewertet. Lisa und Ariane kamen so
nie ueber 80 % und blieben unter der Anzeigeschwelle von 85 %.
Neuer Prompt: nur belegte Fakten, Rolle aus dem Titel bei knapper
Beschreibung, feste Fuenf-Stufen-Skala, Platzhalter statt Beispielinhalt.
Alter Prompt liegt als Backup in server/src/scanner/prompts/.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
JWT_EXPIRES_IN faellt ohne Eintrag in .env jetzt auf 7d statt 12h zurueck.
Doku und .env.example angepasst.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Neuer Admin-Reiter "KI": zeigt die letzten vier Zeichen des hinterlegten
OpenAI-Schluessels samt Quelle, nimmt einen neuen an (vorher gegen
/v1/models geprueft) und laesst je Einsatzzweck das Modell per Dropdown
waehlen - Scanner-Bewertung, Abgleich "bereits beworben", erweiterte Suche.
Die Auswahl kommt live von OpenAI, Vorgaben sind die bisher fest
verdrahteten Modelle. Reasoning-Modelle bekommen reasoning_effort statt
temperature, damit ein Wechsel keinen 400er ausloest.
Schluesselfeld aus dem Scanner-Reiter entfernt; Doku in docs/14-ki.md.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Die Uebernahme aus der Akquise schrieb den Link bisher nur in die Notizen.
Jetzt hat die Opportunity eine Spalte `link`, gefuellt bei Uebernahme und
Kopie; im Dialog steht sie rechts neben der Phase mit Knopf "Oeffnen".
schema.sql traegt den Link fuer aeltere Uebernahmen nach. Die Pruefung liegt
in server/src/link.js und gilt fuer Akquise und Opportunities gleich.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bisher verschwand ein Fund mit der Uebernahme aus Eingang und Archiv.
Beim Durchgehen blieb damit offen, ob er schon angefasst wurde. Jetzt
bleibt der Eintrag stehen und zeigt statt "Opportunity" den blauen Knopf
"Uebernommen" mit Haken; ein Klick springt zur Opportunity.
Dafuer entscheidet nicht mehr IS_OPEN ueber die Listen, sondern die neuen
Regeln IN_INBOX und RETURNED: ein Rueckfaeller (Opportunity im Papierkorb
oder geloescht) gehoert weiter ins Archiv, alles andere bleibt in seiner
Liste. Zaehler und Menuezahl folgen derselben Regel. IS_OPEN bleibt fuer
den Loeschlauf: was zu einer lebenden Opportunity gehoert, wird nicht
weggeraeumt.
Solange die Opportunity lebt, sind Bearbeiten, Loeschen und "Zurueck in
die Akquise" am Eintrag gesperrt - er ist ihr Herkunftsnachweis, und der
Rueckweg von der Opportunity braucht ihn. Das Loeschen weist auch das
Backend ab, nicht nur die Oberflaeche.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Das Secret der App-Registrierung laeuft in Entra ab. Bisher hiess das: jemand
mit SSH-Zugang aendert die .env und startet den Dienst neu - und niemand sieht
vorher, wann es soweit ist. Laeuft es aus, stehen Anmeldung UND
Postfachabgleich still, denn beide haengen an derselben Registrierung.
Neu unter Einstellungen > Anmeldung: Secret eintragen, Ablaufdatum hinterlegen,
Restlaufzeit ablesen. Ab 30 Tagen vor dem Ablauf bekommen Administratoren ueber
jeder Ansicht ein Hinweisband, das direkt dorthin fuehrt; nach dem Ablauf wird
es rot. Der Hinweis reist mit /api/badges mit, das die App ohnehin bei jedem
Laden abruft.
Bewusst so entschieden:
- Das Secret muss dafuer in die Datenbank, entgegen der bisherigen Regel
"keine Geheimnisse in crm_settings". Es liegt deshalb AES-256-GCM-
verschluesselt dort; der Schluessel kommt aus CRM_ENCRYPTION_KEY, ersatz-
weise JWT_SECRET, und steht damit nie im selben Dump.
- Vor dem Speichern holt das CRM mit dem eingegebenen Wert ein Token bei
Microsoft. Ein Tippfehler wird gar nicht erst uebernommen.
- Gelesen wird Datenbank vor .env; der .env-Wert bleibt Rueckfallebene, und
"Hinterlegtes Secret verwerfen" schaltet dorthin zurueck.
- Passt der Schluessel nicht mehr, meldet die Oberflaeche das ausdruecklich,
statt still auf die .env zurueckzufallen - sonst sucht man den Fehler an
der falschen Stelle.
- Das Ablaufdatum wird von Hand eingetragen. Aus Entra lesen braeuchte
Application.Read.All, die die App bewusst nicht hat.
MAIL_CONFIGURED und SSO_CONFIGURED sind dadurch von Konstanten zu den
Funktionen mailConfigured() und ssoConfigured() geworden - die Pruefung muss
jetzt in die Datenbank sehen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Nicht jedes CRM-Konto traegt eine @perinco.de-Adresse. Ohne den Eintrag weist
domainAllowed() diese Leute ab, obwohl Tenant und CRM-Konto stimmen. Auf dem
Server ist MS_SSO_ALLOWED_DOMAINS bereits entsprechend gesetzt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OpenID Connect mit Authorization Code Flow und PKCE, vollstaendig
serverseitig - der Browser sieht weder Tenant- noch Client-ID. Genutzt wird
dieselbe App-Registrierung wie die Postfachanbindung, also kein zweites
Secret; delegiert statt app-only.
Nach dem Token-Tausch beweist ein Aufruf von /me bei Graph, dass das
Zugriffstoken gilt, und liefert die Objekt-ID. Sie landet in der neuen Spalte
crm_users.entra_oid und ist danach die stabile Verknuepfung - die E-Mail-
Adresse eines Menschen kann sich aendern, die Objekt-ID nicht.
Bewusst so entschieden:
- Es werden keine Konten angelegt. Wer kein CRM-Konto mit derselben Adresse
hat, wird abgewiesen; Zugriff vergibt weiter die Nutzerverwaltung.
- Die Anmeldung mit Benutzername und Passwort bleibt fuer alle bestehen -
Notzugang, falls Entra oder das Secret ausfaellt.
- Das CRM-Token kommt als Einmal-Ticket zurueck, nicht in der Adresszeile:
die Rueckleitung ist ein GET und stuende sonst in Browserverlauf und
Apache-Log.
- Keine Signaturpruefung des ID-Tokens und damit keine JWKS-Bibliothek. Es
kommt ueber TLS direkt vom Token-Endpunkt (OIDC Core 3.1.3.7); geprueft
werden aud, tid, nonce und exp, und der Graph-Aufruf belegt den Rest.
Ohne MS_SSO_ENABLED=true bleibt alles aus und die Anmeldemaske sieht aus wie
bisher.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Beides lag bisher nur als nicht eingecheckte Arbeit im Arbeitsverzeichnis,
waehrend auf Gitea nur die Doku dazu stand (docs/12-suche.md). Damit ist
der Code jetzt versioniert.
Globale Suche:
- server/src/routes/search.js: Volltext ueber Kontakte, Opportunities und
Akquise, dazu die erweiterte Suche mit dem Modell des Scanners
- src/components/GlobalSearch.tsx im Kopf der Anwendung; ein Treffer
springt in die Ansicht und oeffnet den Datensatz (navigation.tsx)
ICON CRM:
- server/src/routes/integrations.js liefert die Kontakte mit gesetztem
Haekchen hinaus, server/src/routes/iconCrm.js holt die Kontakte von
drueben herein - beide nur lesend, mit festem Token statt JWT
- server/src/contactBridge.js und src/lib/contactMatch.ts erkennen
Dubletten, src/components/leads/IconMergeDialog.tsx laesst sie
zusammenfuehren
- server/src/ai.js buendelt die OpenAI-Aufrufe
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sonne bzw. Mond in der Ecke oben rechts der Leiste, dahinter ziehen
Wolken in zwei Lagen langsam von links nach rechts (reines CSS, nahtlose
Kacheln). Im hellen Modus fallen alle 16-24 s zwei bis drei
Sonnenstrahlen diagonal ueber den Bildschirm. Bernstein bei Tag,
Lavendel und Sterne bei Nacht. Bei prefers-reduced-motion still.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Eisblau in hell und dunkel. Flocken fallen per Canvas und sammeln sich
am unteren Fensterrand in einer Hoehenkarte, die per Diffusion
geglaettet wird; nach rund vier Minuten ist die Decke voll (26 px).
Bei prefers-reduced-motion bleibt es still.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Schieferblau in hell und dunkel. Ein paar Tropfen fallen per Canvas
ueber den Bildschirm und zerspritzen am unteren Rand; die Wolken der
oberen Leiste leuchten alle 7-18 s auf (Maske = Wolken-SVG). Bei
prefers-reduced-motion bleibt es still.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Neu gefundene Projekte mit Treffer werden einmalig per gpt-5.6-luna mit den
Akquise-Eintraegen und Opportunities der letzten N Tage (Vorgabe 14)
verglichen. Passt ein Eintrag, zeigt der Scanner "bereits beworben!" samt
Begruendung. Schalter und Zeitraum (Tage/Wochen) in Einstellungen -> Scanner,
Neupruefung von Hand im Detail.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Kopier-Symbol auf Kachel, Pipeline-Karte und Listenzeile sowie "Kopieren"
im Dialog. Ein Dialog fragt nach einem oder mehreren Beratern (aus der
Beraterliste der Akquise, ohne den eigenen) und der Phase der Kopie
(Standard: Neu). Neuer Endpoint POST /api/opportunities/:id/copy legt je
Berater eine Kopie mit Projektdaten, Ansprechpartnern, Zustaendigem und
acquisition_id an; Interaktion und naechster Schritt bleiben beim Original.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Im Dialog einer Opportunity aus der Akquise nimmt "Zurueck in die Akquise"
eine versehentliche Uebernahme zurueck: alle Opportunities aus dem Eintrag
wandern in den Papierkorb, der Eintrag steht mit seinem Funddatum wieder in
Eingang bzw. Archiv. Neue Spalte crm_opportunities.acquisition_id, damit bei
mehreren Beratern alle gefunden werden. Wiederherstellen haengt den Eintrag
wieder an die Opportunity.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
requireAuth hat den Benutzer mit einer ausgeschriebenen Spaltenliste geladen,
in der theme und theme_mode fehlten. GET /api/auth/me antwortete deshalb mit
null, und der ThemeProvider hat das beim Neuladen als "nichts gewaehlt"
gelesen: die Anzeige fiel auf perinco/System zurueck und hat den
localStorage-Zwischenspeicher gleich mit ueberschrieben. Direkt nach dem Klick
und nach dem Anmelden sah es richtig aus, weil PATCH /me den geaenderten Wert
selbst zurueckgibt und der Login SELECT * benutzt - nur das Neuladen nicht.
Dazu ein Test, der die Spaltenliste mit den Feldern von publicUser()
vergleicht, damit ein neues Benutzerfeld nicht wieder still verloren geht.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Anlass: Bei einem Kontakt kam das Foto, beim naechsten nicht. Der Vergleich
der beiden Profilseiten zeigt warum - das zweite Profil liefert als
og:image nur LinkedIns Ersatzgrafik (static.licdn.com/aero-v1/sc/h/...),
weil die Sichtbarkeit des Fotos auf "Meine Kontakte" steht. Angemeldet
sieht man es, der Abruf hier ist es nicht.
Zwei Konsequenzen:
* Die Rueckfallebene "erste media.licdn.com-Adresse im Quelltext" faellt
weg. Dieselbe Seite enthaelt 24 solcher Adressen: Firmenlogos,
Beitragsbilder und die Fotos der "aehnlichen Profile" am Rand. Nur die
Open-Graph-Vorschau gehoert nachweislich zum aufgerufenen Profil -
alles andere haette irgendwann ein fremdes Gesicht an einen Kontakt
gehaengt.
* Die Meldung sagt jetzt, was wirklich los ist: "nur fuer Kontakte
sichtbar oder es gibt keines" statt "hat kein eigenes Foto". Von
aussen sind die beiden Faelle nicht unterscheidbar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Drei Verbesserungen an den Kontakten:
* Beim Anlegen ist der angemeldete Benutzer voreingestellt zustaendig.
Bisher stand dort der erste Benutzer der Liste - fast immer falsch.
* Wird eine LinkedIn-Adresse hinterlegt, holt das CRM das oeffentliche
Profilfoto und setzt es als Kontaktfoto: beim Verlassen des Feldes
einmal je Adresse, solange kein Foto gesetzt ist, und auf Klick ueber
den Knopf daneben. Der Abruf laeuft ueber das Backend
(server/src/linkedinPhoto.js, POST /api/leads/linkedin-photo), weil
ihn die Same-Origin-Policy im Browser verhindert. Gelesen wird die
Open-Graph-Vorschau der Profilseite; Herkunft, Groesse und Antwortzeit
des Bildes werden geprueft, Platzhalter-Silhouetten abgewiesen.
Schlaegt der Abruf fehl, steht der Grund unter dem Feld.
* In der Netzwerkansicht hebt ein Klick auf freie Flaeche die Auswahl
auf - das Diagramm sieht danach aus wie beim Wechsel in die Ansicht.
Ein Ziehen des Hintergrunds (ab 4 px) laesst die Auswahl stehen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die eigenstaendige Vorgaenger-App unter scanner.perinco.de ist auf dem Server
entfernt: Unit project-scanner-backend (Port 5005), beide Apache-Vhosts, das
Let's-Encrypt-Zertifikat samt Renewal-Config, /var/www/Projekt Scanner (486 MB)
und die Datenbank project_scanner (Dump unter /root/backups). Damit entfallen
die LEGACY_*-Variablen und das Importskript, dessen Quelle es nicht mehr gibt.
/root/.cache/ms-playwright bleibt bewusst stehen: der Cache stammt aus der
Installation der alten App, liegt aber ausserhalb beider Verzeichnisse und wird
vom CRM-Scanner benutzt - playwright ist auf 1.60.0 gepinnt, damit es genau
dieser Build (chromium-1223) bleibt. Der Hinweis steht jetzt in README und
docs/06-betrieb.md, damit ihn beim naechsten Aufraeumen niemand mitnimmt.
SCANNER_SCHEDULER_OFFSET geht auf 0: der Versatz sollte verhindern, dass beide
Instanzen mit denselben Portal-Cookies gleichzeitig losziehen. Ohne zweite
Instanz hat er keinen Zweck mehr, die Mechanik bleibt fuer kuenftige Erststarts
im Code.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bei der Uebernahme aus der Akquise verschwand die wichtigste Angabe nach
dem Titel: fuer wen das Projekt laeuft. Die Opportunity hatte kein Feld
dafuer, also schrieb die Uebernahme den Namen in den Herkunftsvermerk der
Notizen - in Pipeline, Liste und Kacheln war er damit nicht zu sehen, und
suchen liess sich nur im Notiztext.
crm_opportunities.consultant traegt ihn jetzt selbst. Genau ein Name je
Opportunity: passt ein Fund zu drei Beratern, entstehen bei der
Uebernahme drei Opportunities. Sichtbar in Pipeline-Karte, Kachel,
Papierkorb und als sortierbare Spalte direkt hinter dem Titel; die Suche
fasst ihn mit ein, und im Dialog kommt die Auswahl aus derselben Liste
wie in der Akquise (Einstellungen -> Akquise), damit nicht "Nico" und
"Nico N." nebeneinander entstehen.
Bestehende Opportunities holt migrateOpportunityConsultant() beim Start
aus ihren Notizen nach - nur dort, wo die Spalte leer ist. Damit ist der
Lauf wiederholbar und ueberschreibt nichts, was seither von Hand gesetzt
wurde; ein Merker in crm_settings ist dafuer nicht noetig. Der Text in
den Notizen bleibt stehen: er ist der Herkunftsnachweis samt Anbieter,
Kanal und Link.
Der Namenszusatz im Titel entfaellt wieder. Er war gestern dazugekommen,
damit sich mehrere Opportunities aus einem Fund unterscheiden liessen -
mit einer eigenen Spalte ist er nur noch Rauschen.
Nebenbei: der Block, der won_at nachzieht, stand zweimal in schema.sql.
Idempotent und damit harmlos, aber eine Kopie - jetzt einmal.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Neon in der Nacht: fast schwarze Flaechen mit blauem Stich, violettes
Leuchten, Blaustahl statt Neutralgrau und Kanten von 2 px - scharf genug
fuer HUD-Elemente, aber nicht eckig, das ist schon Pixel Art. Schatten
sind hier kein Schatten, sondern ein Schein: farbige Kontur plus weicher
Halo in der Markenfarbe. Schrift ist Chakra Petch, die Feldbeschriftungen
laufen gesperrt.
Der Akzent ist bewusst Violett und nicht Neon-Cyan: auf brand-500 und
brand-600 steht 69 Mal weisse Schrift, und auf Cyan waere die nicht zu
lesen. Cyan sitzt deshalb nur in --color-brand-accent und in den
Statusfarben, wo dunkler Text darauf steht.
Der helle Modus ist der Konzern bei Tageslicht: kuehles Blaugrau, dasselbe
Violett nur dunkler, und aus dem Leuchten wird ein knapper kalter Schatten -
ein Halo auf hellem Grund sieht nach Fehler aus, nicht nach Neon.
Es waren vier Zeilen ausserhalb von index.css: die Whitelist in
userFields.js, die Liste in src/types.ts mit ihrer Beschriftung, die
Whitelist im Inline-Skript und die Schrift im Google-Fonts-Aufruf. Keine
Komponente wurde angefasst.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Neben dem Design des Hauses ("perinco") gibt es "Pixel Art" und
"Outdoor", jedes in hell und dunkel. Die Wahl steht neben dem
Hell/Dunkel-Schalter im Kopf der App.
Sie gehoert dem BENUTZER und nicht dem Browser: crm_users.theme und
crm_users.theme_mode, gesetzt ueber PATCH /api/auth/me, das jeder fuer
sich selbst darf. Wer sich an einem anderen Rechner anmeldet, findet sein
Design wieder, und zwei Benutzer an derselben Maschine kommen sich nicht
in die Quere. Der localStorage bleibt als Zwischenspeicher daneben, damit
das Inline-Skript in index.html die Klassen vor dem ersten Frame setzen
kann - ohne das blitzt beim Laden das Standarddesign auf. Das hat eine
sichtbare Folge: melden sich zwei Leute an demselben Rechner an, sieht
der zweite fuer einen Augenblick das Design des ersten.
Der ThemeProvider steht deshalb in main.tsx jetzt unter dem AuthProvider
- er liest den Benutzer.
Keine Komponente wurde umgefaerbt. Im Markup steht nirgends eine feste
Farbe, sondern durchgaengig ink-*, brand-*, canvas und surface; Tailwind
v4 loest auch --radius-*, --shadow-* und die Schriften ueber Variablen
auf. Ein Theme tauscht also nur Werte, und deshalb kann Pixel Art alle
380 abgerundeten Ecken eckig machen, ohne eine Klasse anzufassen.
Zwei Dinge waren Voraussetzung:
- Der helle Block eines Themes braucht :not(.dark). html.theme-x hat
eine Klasse mehr in der Spezifitaet als .dark und wuerde den
Dunkelmodus sonst ueberstimmen.
- Auf brand-500/600 steht 69 Mal weisse Schrift. Jedes Theme braucht
dort einen ausreichend dunklen Ton - ein helles Pastell waere
unlesbar.
Die Pixelschrift (Silkscreen) sitzt nur in --font-display, also in den
Ueberschriften und den Feldbeschriftungen; labelClass tragt dafuer die
neue Klasse "field-label". Der Fliesstext bleibt Nunito Sans: die Listen
haben bis zu acht Spalten bei 11-13 px, und eine Pixelschrift waere darin
nicht mehr zu lesen. Outdoor bringt Cabin fuer beides mit.
server/test/userFields.test.mjs prueft die Werte und dass die Liste der
Farbwelten in userFields.js und src/types.ts nicht auseinanderlaeuft -
sonst zeigt die Auswahl ein Design an, dessen Speichern das Backend
abweist, und niemand weiss warum.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ein gefundenes Projekt passt oft zu mehr als einem Berater, und fuer
jeden geht eine eigene Bewerbung heraus. Das Feld "Berater" liess bisher
nur einen Namen zu.
Gespeichert wird eine kommagetrennte Liste in crm_acquisitions.consultant
(auf VARCHAR(500) erweitert, Migration in db.js) und keine eigene
Zuordnungstabelle: die Namen sind reiner Text, die Auswahlliste in
crm_acquisition_options ist eine Pflegehilfe und kein Fremdschluessel.
Suche, Sortierung und Anzeige der Liste arbeiten damit weiter auf einem
Feld. Die Funktionen zum Zerlegen stehen in acquisitionRules.js, das
Gegenstueck fuer das Frontend in src/types.ts, geprueft von
server/test/acquisition.test.mjs.
Zerlegt wird an vier Stellen:
- Uebernahme: je Berater eine Opportunity, alle in einer Transaktion.
Ihre Titel tragen den Namen in Klammern, weil die Opportunity kein
eigenes Feld fuer den Berater hat und in Pipeline und Liste sonst
identische Zeilen stehen; bei einem einzigen Berater bleibt der Titel
unveraendert. In den Notizen steht neben dem eigenen Berater auch, mit
wem er sich das Projekt teilt. Der Eintrag merkt sich die erste
Opportunity - sie entscheidet nur darueber, ob er wieder im Eingang
auftaucht.
- Verlauf (crm_acquisition_history): ein Berater je Zeile. Ein Eintrag
mit drei Beratern sind drei Bewerbungen, "Nico, Lisa" waere sonst ein
eigener Schluessel neben "Nico" und "Lisa".
- Dashboard: dieselbe Zaehlung. Die Summe der Balken liegt damit ueber
der Gesamtzahl "Bewerbungen", die weiter die Eintraege zaehlt.
- Auswahlliste pflegen: Umbenennen ersetzt den Namen innerhalb der
Liste, Loeschen zaehlt auch, wer nur einer von mehreren ist. Ein
Gleichheitsvergleich uebersah beides.
In der Oberflaeche haengt das Auswahlfeld jeweils einen Namen an, die
Gewaehlten stehen als Plaketten darunter und lassen sich einzeln
entfernen; ein bereits gewaehlter Berater verschwindet aus der Liste.
Bewusst kein <select multiple>: Strg-Klick ist mit der Maus unauffindbar
und mit einer Beruehrung gar nicht bedienbar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Legacy-Import war ein Erststart-Werkzeug: er brach bei vorhandenen
Agenten ab und schrieb immer auch Einstellungen und Portale mit. Um
spaeter einzelne Suchagenten aus project_scanner nachzuziehen, gab es
keinen Weg.
--agents-only laesst Einstellungen, Portale, Projekte und Treffer
unberuehrt und laeuft additiv: vorhandene Agenten blockieren nicht mehr,
sondern werden am Namen erkannt und uebersprungen, damit im CRM
bearbeitete Agenten nicht ueberschrieben werden. Die Id der Quelle wird
nur uebernommen, solange sie im Ziel frei ist.
--skip=Name[,Name] laesst Agenten nach Namen aus, ohne Ruecksicht auf
Gross- und Kleinschreibung.
--force ist mit --agents-only gesperrt: es wuerde Projekte und Treffer
loeschen, die der Lauf gar nicht anfasst.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Loeschen in der Akquise war ein echtes DELETE: der Eintrag stand danach
in keiner Liste, auch nicht im Archiv, und war nicht zurueckholbar. Jetzt
setzt es `deleted_at`/`deleted_by`, die Zeile bleibt 90 Tage stehen.
Der Papierkorb ist die eine Ausnahme von der Regel, dass diese Tabelle
keinen Zustand fuehrt: Loeschen von Hand ist eine Entscheidung, kein
Ablauf. Was dort liegt, blenden alle anderen Abfragen ueber NOT_DELETED
aus - Eingang, Archiv, Menuezahlen und Dashboard. Der Aufraeumlauf ueber
`found_at` laesst geloeschte Zeilen ausdruecklich liegen, sonst waere ein
alter Fund im Papierkorb sofort weg; der Papierkorb raeumt ab
`deleted_at`.
Zwei Rueckwege, deshalb zwei Routen. `/reopen` (bisher `/restore`) holt
aus dem Archiv in den Eingang und setzt das Funddatum auf heute.
`/restore` holt aus dem Papierkorb zurueck und laesst das Funddatum in
Ruhe - der Eintrag soll dort auftauchen, wo er hingehoert, also im
Archiv, wenn er alt ist. Die Meldung nennt das Ziel.
Dazu `DELETE /:id/permanent` und `POST /trash/empty`. Im Papierkorb wird
nicht gepflegt: Bearbeiten und Uebernehmen antworten 409.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Im Archiv setzte der Stift nur `editing` - das Formular stand dort nicht,
also passierte sichtbar nichts. Es wird jetzt auch im Archiv gezeigt,
aber nur beim Bearbeiten: eingetragen wird weiterhin im Eingang.
Dazu ein Weg zurueck. `POST /api/acquisitions/:id/restore` setzt
`found_at` auf heute und leert `converted_at` samt `opportunity_id` -
ohne Letzteres haelt die Uebernahme einen Rueckfaeller im Archiv fest,
gleich welches Datum er traegt. Eine Spalte "wiederhergestellt" gibt es
bewusst nicht; die Tabelle fuehrt keinen Zustand.
Der Pfeil erscheint nur im Archiv. Ein nie uebernommener Eintrag wird
ohne Rueckfrage zurueckgeholt, ein Rueckfaeller mit - dabei faellt der
Verweis auf die geloeschte Opportunity weg. Fuer diese Rueckfrage kennt
`ConfirmDialog` jetzt `tone="neutral"`: ein roter Knopf an einer
harmlosen Stelle nimmt der Farbe ihre Bedeutung.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Wer eine Bewerbung uebernimmt, hat den Berater bereits gesprochen. Die
Opportunity in der Phase "Neu" anzulegen bedeutete, sie sofort von Hand
weiterzuschieben. Sie startet jetzt direkt in "Erstgespraech Berater";
Toast, Knopf-Hinweis und Benutzeranleitung nennen dieselbe Phase.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die Sperre gegen parallele Laeufe schuetzt gegen Ueberholen, nicht gegen
einen Lauf, der gar nicht zurueckkommt. Haengt ein Browser oder steht eine
Verbindung, laeuft das finally nie - pipelineRunning bleibt true und der
Scanner sucht bis zum naechsten Neustart des Dienstes nicht mehr. Das ist
schlimmer als die Ueberlappung, gegen die die Sperre da ist.
Jetzt merkt sich die Pipeline den Startzeitpunkt. Steht die Sperre laenger
als eine Stunde, gibt der naechste Aufruf sie frei und startet neu.
Dokumentiert in docs/03-scanner.md, mit den Messwerten des Vorfalls vom
26.08.2026 in der alten App: fuenf Pipeline-Starts in 16 Minuten, 31
chrome-headless-shell-Prozesse, 1,62 GB RSS, Load Average 126 auf 4 Kernen,
Swap zu 100 Prozent gefuellt. Die alte App hatte die Sperre nicht; der
Guard dort ist mit diesem Commit nachgezogen worden.
Zur Abgrenzung festgehalten: die Chromium-Prozesse waren kein Leck. Alle
Scraper schliessen ihren Browser in einem finally. Es waren fuenf
gleichzeitige Laeufe mal mehrere Boersen.
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>
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>
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>
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>
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>
