Eingehende E-Mails – Funktionsweise und Datenmodell

Speicherung der eingelesenen Nachrichten, Einlese- und Verarbeitungskette, Pipeline-Übergänge, Hintergrundaufgaben und Berechtigungen für Betreiber und Prüfer.

Überblick

Das Modul speichert die aus Gmail-Postfächern eingelesenen Nachrichten, verarbeitet sie mit Regeln und KI-Klassifizierung und verknüpft sie mit Rechnungen, Aufgaben oder Partnern. Rohnachricht und Anhänge gehen in die Dokumentenzentrale. Die Oberfläche prüft die alte Basis-Routenberechtigung (Zugriff, Ändern); eine Funktionsberechtigung gibt es nur für das SQL-Debug.

Datenmodell

Die Tabellennamen tragen in der Datenbank das eigene Präfix der Installation.

Tabelle	Rolle
`email_message`	Nachrichtenkopf, Geschäftsstatus und Pipeline-Zustand
`email_content`	Nachrichtentext
`email_attachment`, `email_document`	Anhänge (alter Speicher) und Verknüpfung zur Dokumentenzentrale
`email_link`	Verknüpfungen zu Rechnungen, Aufgaben, Partnern
`email_pipeline_log`	Zeitleiste der Pipeline-Übergänge
`email_proposal`	KI-Vorschläge mit Konfidenz
`doc`, `doc_link`, `document`	Dokumentenzentrale und alter Dokumentenspeicher

Einlesekette

Das manuelle Einlesen (syncGmail) und die Hintergrundaufgabe durchlaufen dieselbe Kette für jede aktive Quelle mit dem Anbieter Gmail; andere Anbieter werden mit Protokolleintrag übersprungen. Ohne Quelle läuft eine Ersatzkonfiguration aus den Installationseinstellungen. Je Nachricht:

Gmail-Nachricht abrufen, Dublettenprüfung per Hash.
E-Mail-Filterregeln (überspringen, ignorieren, verknüpfen).
Rohe .eml, Nachrichtenzeile, Verknüpfung per Kontaktfilter, Aktualisierung des Kontaktstamms.
.eml und Anhänge in die Dokumentenzentrale (Dlbtdocstore::addDocument; Firma aus der Quelle oder resolveCompanyForEmail) oder in den alten Drive- bzw. lokalen Speicher.
PDF-Textextraktion, PDF-basierter Nachfilter.
KI-Klassifizierung, falls aktiviert: automatisches Überspringen oder Ignorieren, automatische Verknüpfung über der Schwelle, sonst ein Vorschlag.
Austausch des Gmail-Labels gegen das Suffix für verarbeitet oder Fehler.

Pipeline-Übergänge und manuelle Aktionen

Der manuelle Geschäftsstatus wechselt nur zwischen new und ignored.
Zulässige manuelle Übergänge: PENDING_APPROVAL → PROCESSED, IGNORED, SKIPPED; INGESTED, FILTERED, AI_*, ERROR → IGNORED, SKIPPED. Aus einem Endzustand gibt es keinen Übergang. Beim Wechsel auf PROCESSED wird der wartende Befehl ausgeführt (Aufgabe über task/task::addTask, Zuordnung).
approveProposal, rejectProposal: Vorschlag mit Übergang genehmigen oder ablehnen. aiSuggestionApprove legt die Verknüpfung an und setzt verarbeitet; aiSuggestionReject löscht die automatischen Verknüpfungen und setzt auf neu zurück.
createTaskFromEmail: Titel höchstens 255 Zeichen, Frist als JJJJ-MM-TT; Verknüpfung, Kommentar, Anhangsbindung, Status verarbeitet.
linkEmail: manuelle Zuordnung, auch zu mehreren Zielen; searchTargets: Suche nach Rechnung, Aufgabe, Partner; listCompaniesForSelect: aktive Firmen ohne Inhaltsfilter.
Wartungsstapel: extractPdfsExisting und aiClassifyExisting (1–50), cleanupLegacyAttachments (ratenbegrenzt), applyRulesToExisting (bis 1000 neue Nachrichten), backfillContacts (bis 5000).
createFilterRule: Regel aus einer Nachricht; Überspringen löscht die Nachricht sofort, Ignorieren setzt den Status. createFilterAndDelete ist ein alter Alias.
delete: löscht Nachrichten mit ihren Dateien (Drive-Dateien mit Wiederholung, lokale Dateien, Label-Wiederherstellung, Datenbank-Kaskade).

Hintergrundaufgaben

Aufgabe	Funktion
`email`	Einlesen und lokale Pflege: Zwischenverzeichnis höchstens 256 MB, verwaiste Dateien älter als 3 Tage werden gelöscht, je Lauf höchstens 25 lokale Zeilen auf Drive hochgeladen
`email_commands`	sucht in `INGESTED`-Nachrichten das Aufgabenpräfix des Systems, einen Anweisungsblock oder eine Markierung → `PENDING_APPROVAL` oder `FILTERED`
`email_ai`	KI-Vorschlag in `email_proposal`; über der Schwelle `PROCESSED`, darunter `PENDING_APPROVAL`; bei Fehler dreimal `AI_RETRY`, dann `ERROR`

Alle drei sind global geplant und lassen sich in den Systemeinstellungen des Moduls ein- und ausschalten. Einstiegspunkt ist der katalogseitige Controller email/email.

Berechtigungen

Ebene 1: Liste und Details mit Basis-Zugriffsrecht; jeder ändernde Endpunkt mit Basis-Änderungsrecht (Firmenauswahl und Zielsuche mit Zugriffsrecht).
Ebene 2: nur der Schlüssel debug wird geprüft; der Listenschlüssel wird nicht mit canAction geprüft.
Ebene 3: einen inhaltlichen (Firmen-)Bereich gibt es im Code nicht.

Bekannte Einschränkungen

Im Schritt email_ai ist der KI-Aufruf laut Code ein Platzhalter; er benötigt einen API-Schlüssel.
Liste und Endpunkte filtern nicht nach Inhaltsberechtigung, und die Funktion ist im Funktionskatalog nicht eingestuft.

Related topics: Eingehende E-Mails Hintergrundaufgabe KI-Vorschlag Berechtigungen

Request consultation Back to home