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>
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>
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>
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>
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>
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>
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>
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>
