Beérkező e-mailek – működés és adatmodell

A beolvasott levelek tárolása, a beolvasási és feldolgozási lánc, a pipeline-átmenetek, a háttérfeladatok és a jogosultság leírása üzemeltetőknek.

Áttekintés

A modul a Gmail-postafiókokból beolvasott leveleket tárolja, szabályok és AI-besorolás alapján feldolgozza, és számlához, feladathoz vagy partnerhez köti. A levél nyers alakja és a mellékletek a dokumentumtárba kerülnek. A felület a régi alap útvonal-jogot (hozzáférés, módosítás) ellenőrzi; funkciójog csak az SQL-debugra van.

Adatmodell

A táblanevek a telepítés saját előtagjával állnak az adatbázisban.

Tábla	Szerep
`email_message`	a levél fejadatai, üzleti állapot és pipeline-állapot
`email_content`	a levél törzse
`email_attachment`, `email_document`	mellékletek (régi tár) és a dokumentumtári kötés
`email_link`	a levél kapcsolatai számlához, feladathoz, partnerhez
`email_pipeline_log`	a pipeline-átmenetek idővonala
`email_proposal`	AI-javaslatok konfidenciával
`doc`, `doc_link`, `document`	dokumentumtár és a régi dokumentum-tár

Beolvasási lánc

A kézi beolvasás (syncGmail) és a háttérfeladat ugyanazt a láncot futtatja minden aktív, Gmail-szolgáltatójú forrásra; más szolgáltató naplózva kimarad. Forrás híján a telepítés-beállításból összeállított tartalék konfiguráció fut. Levelenként:

Gmail-üzenet lekérése, hash alapú duplikátum-szűrés.
Levélszűrő-szabályok (kihagyás, figyelmen kívül hagyás, kapcsolás).
Nyers .eml, levél-sor, kapcsolat-szűrő szerinti link, kontakt-törzs frissítése.
A .eml és a mellékletek a dokumentumtárba (Dlbtdocstore::addDocument; a cég a forrásból vagy resolveCompanyForEmail), vagy a régi Drive- vagy helyi tárba.
PDF szöveg-kinyerés, PDF-alapú utószűrő.
AI-besorolás, ha engedélyezett: automatikus kihagyás vagy figyelmen kívül hagyás, küszöb feletti automatikus kapcsolás, egyébként javaslat.
Gmail-címke cseréje a feldolgozott vagy a hiba utótagra.

Pipeline-átmenetek és kézi műveletek

Kézi üzleti állapot csak new és ignored között váltható.
Engedett kézi átmenetek: PENDING_APPROVAL → PROCESSED, IGNORED, SKIPPED; INGESTED, FILTERED, AI_*, ERROR → IGNORED, SKIPPED. Lezárt állapotból nincs átmenet. PROCESSED-re váltáskor a függő parancs (feladat létrehozása task/task::addTask-kal, összerendelés) végrehajtódik.
approveProposal, rejectProposal: javaslat jóváhagyása vagy elutasítása átmenettel. aiSuggestionApprove kapcsolatot hoz létre és feldolgozottá tesz; aiSuggestionReject törli az automatikus kapcsolatokat és visszaállítja újra.
createTaskFromEmail: cím legfeljebb 255 karakter, határidő ÉÉÉÉ-HH-NN formában; kapcsolat, komment, csatolmány-kötés, feldolgozott állapot.
linkEmail: kézi összerendelés, több cél is; searchTargets: számla, feladat, partner kereső; listCompaniesForSelect: aktív cégek tartalmi szűrés nélkül.
Karbantartó kötegek: extractPdfsExisting és aiClassifyExisting (1–50), cleanupLegacyAttachments (sebességkorláttal), applyRulesToExisting (legfeljebb 1000 új levél), backfillContacts (legfeljebb 5000).
createFilterRule: szabály egy levélből; kihagyásnál a levelet azonnal törli, figyelmen kívül hagyásnál állapotot állít. createFilterAndDelete régi álnév.
delete: levél törlése a fájlokkal (Drive-fájlok újrapróbálással, helyi fájlok, címke-visszaállítás, adatbázis-kaszkád).

Háttérfeladatok

Feladat	Mit csinál
`email`	beolvasás és helyi karbantartás: átmeneti könyvtár legfeljebb 256 MB, a 3 napnál régebbi árva fájlok törlése, futásonként legfeljebb 25 helyi sor feltöltése Drive-ra
`email_commands`	az `INGESTED` levelekben a rendszer feladat-előtagját, utasítás-blokkját vagy jelölő címkéjét keresi → `PENDING_APPROVAL` vagy `FILTERED`
`email_ai`	AI-javaslat az `email_proposal` táblába; küszöb felett `PROCESSED`, alatta `PENDING_APPROVAL`; hibánál háromszor `AI_RETRY`, majd `ERROR`

A három feladat globálisan ütemezett, a modul rendszerbeállításában kapcsolható be és ki. Belépési pontjuk a katalógus oldali email/email vezérlő.

Jogosultság

1. réteg: lista és részletek alap hozzáférési joggal; minden módosító végpont alap módosítási joggal (a cégválasztó és a célkereső hozzáférési joggal).
2. réteg: csak a debug kulcs van ellenőrizve; a lista kulcsa nem kerül canAction-ellenőrzésre.
3. réteg: tartalmi (cég) hatókör a kódban nincs.

Ismert korlátok

Az email_ai lépésben az AI-hívás a kód szerint helyőrző; működéséhez API-kulcs szükséges.
A lista és a végpontok nem szűrnek tartalmi jogra, és a funkció nincs a funkció-katalógusban besorolva.

Kapcsolódó témák: beérkező levelek háttérfeladat AI-javaslat jogosultság

Konzultáció kérése Vissza a főoldalra