Update README.md with detailed information on AI-based modifications in EspoCRM
This commit is contained in:
157
README.md
157
README.md
@@ -1,2 +1,157 @@
|
|||||||
# espocrm
|
KI-basierte Bearbeitung von EspoCRM: Struktur und Funktionsweise
|
||||||
|
|
||||||
|
Unter der Annahme, dass die KI direkten Zugriff auf das Dateisystem des EspoCRM-Servers hat (z. B. via SSH, API-Integration oder lokales Scripting), kann sie EspoCRM modifizieren, indem sie JSON-basierte Metadata-Dateien bearbeitet. EspoCRM ist modular aufgebaut und speichert Konfigurationen für Entitäten, Felder, Beziehungen, Views und Layouts in diesen Dateien. Änderungen erfolgen idealerweise im custom/-Verzeichnis, um Core-Dateien nicht zu überschreiben und Upgrades zu erleichtern. Die KI würde Dateien lesen, parsen (z. B. als JSON), modifizieren und speichern – gefolgt von einem Rebuild-Prozess, um die Änderungen anzuwenden.
|
||||||
|
|
||||||
|
EspoCRM basiert auf PHP (Backend) und Backbone.js (Frontend), mit einer rekursiven Merging-Mechanik: Custom-Dateien überschreiben oder erweitern Core-Definitionen. Keine integrierte KI-Schnittstelle existiert, aber mit Dateizugriff kann die KI automatisierte Anpassungen vornehmen, z. B. Felder hinzufügen, Views anpassen oder Beziehungen definieren. Nachfolgend detaillierte Infos basierend auf der offiziellen Dokumentation und Community-Beiträgen.
|
||||||
|
1. Relevante Dateipfade und Verzeichnisstruktur
|
||||||
|
|
||||||
|
Alle relevanten Dateien liegen im JSON-Format und werden in einer hierarchischen Struktur organisiert. Die KI sollte immer im custom/Espo/Custom/Resources/metadata/-Ordner arbeiten, da Änderungen hier persistent sind und nicht bei Updates verloren gehen. Core-Dateien (z. B. unter application/Espo/Resources/metadata/) dienen als Referenz, aber sollten nicht modifiziert werden.
|
||||||
|
|
||||||
|
Hauptverzeichnis für Customizations: custom/Espo/Custom/Resources/
|
||||||
|
Unterordner: metadata/ (für Definitionsdateien wie entityDefs, clientDefs).
|
||||||
|
Weitere Unterordner: layouts/ (für UI-Layouts), i18n/ (für Übersetzungen, falls relevant).
|
||||||
|
Spezifische Dateitypen und Pfade:
|
||||||
|
entityDefs/{EntityType}.json: Definiert Entitäten (z. B. Account, Contact oder custom wie Project). Pfad: custom/Espo/Custom/Resources/metadata/entityDefs/Account.json.
|
||||||
|
Kontrolliert: Felder, Beziehungen (Links), Indizes, Collections (z. B. Sortierung in Listen).
|
||||||
|
clientDefs/{EntityType}.json: Definiert Frontend-Konfigurationen für Entitäten. Pfad: custom/Espo/Custom/Resources/metadata/clientDefs/Account.json.
|
||||||
|
Kontrolliert: Views (z. B. Edit-View), Controller, Modelle, Setup-Handler für dynamische UI-Anpassungen.
|
||||||
|
layouts/{EntityType}/{LayoutType}.json: Definiert UI-Layouts (z. B. Detail-View, List-View). Pfad: custom/Espo/Custom/Resources/layouts/Account/detail.json.
|
||||||
|
LayoutTypes: detail, list, edit, kanban, etc.
|
||||||
|
fields/{FieldType}.json: Globale Feld-Definitionen (z. B. für Address oder Phone). Pfad: custom/Espo/Custom/Resources/metadata/fields/address.json.
|
||||||
|
Kontrolliert: Feldtypen, Views für spezifische Felder (z. B. custom View für Phone mit Click-to-Call).
|
||||||
|
scopes/{EntityType}.json: Definiert Entity-Scopes (z. B. ob eine Entität importierbar ist). Pfad: custom/Espo/Custom/Resources/metadata/scopes/Project.json.
|
||||||
|
Andere (weniger häufig): aclDefs/ für Zugriffsrechte, selectDefs/ für Filter, recordDefs/ für Record-spezifische Logik.
|
||||||
|
|
||||||
|
Falls die KI ein neues Modul erstellt: custom/Espo/Modules/{ModuleName}/Resources/metadata/ – ähnliche Struktur, aber modular getrennt.
|
||||||
|
docs.espocrm.com
|
||||||
|
2. Dateiformate und JSON-Strukturen
|
||||||
|
|
||||||
|
Alle Dateien sind im JSON-Format. Die KI muss gültiges JSON parsen und schreiben (z. B. mit Bibliotheken wie json in Python). Strukturen sind hierarchisch: Objekte für Felder/Links, Arrays für Optionen/Listen.
|
||||||
|
|
||||||
|
entityDefs/{EntityType}.json (Format-Beispiel für eine Entität wie Account):
|
||||||
|
JSON
|
||||||
|
|
||||||
|
{
|
||||||
|
"fields": {
|
||||||
|
"name": {
|
||||||
|
"type": "varchar",
|
||||||
|
"required": true,
|
||||||
|
"len": 255
|
||||||
|
},
|
||||||
|
"status": {
|
||||||
|
"type": "enum",
|
||||||
|
"options": ["Active", "Inactive"],
|
||||||
|
"default": "Active"
|
||||||
|
},
|
||||||
|
"employeeCount": {
|
||||||
|
"type": "int"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"links": {
|
||||||
|
"account": {
|
||||||
|
"type": "belongsTo",
|
||||||
|
"entity": "Account",
|
||||||
|
"foreign": "projects"
|
||||||
|
},
|
||||||
|
"teams": {
|
||||||
|
"type": "hasMany",
|
||||||
|
"entity": "Team",
|
||||||
|
"relationName": "EntityTeam"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"collection": {
|
||||||
|
"sortBy": "createdAt",
|
||||||
|
"asc": false,
|
||||||
|
"boolFilters": ["onlyMy"]
|
||||||
|
},
|
||||||
|
"indexes": {
|
||||||
|
"name": {
|
||||||
|
"columns": ["name"]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
Felder (fields): Schlüssel = Feldname, Wert = Objekt mit type (z. B. varchar, enum, link), required (bool), options (Array für Enums), etc.
|
||||||
|
Links: Beziehungen (belongsTo für 1:1, hasMany für 1:N, etc.).
|
||||||
|
Collection: Für Listen-Views (Sortierung, Filter).
|
||||||
|
Auslösen: Hinzufügen eines Felds triggert bei Rebuild eine Datenbankänderung (neue Spalte in der Tabelle). Beziehungen erstellen Middle-Tables bei Many-to-Many.
|
||||||
|
docs.espocrm.com
|
||||||
|
|
||||||
|
clientDefs/{EntityType}.json (Format-Beispiel):
|
||||||
|
JSON
|
||||||
|
|
||||||
|
{
|
||||||
|
"controller": "controllers/record",
|
||||||
|
"collection": "collection",
|
||||||
|
"model": "model",
|
||||||
|
"views": {
|
||||||
|
"list": "views/record/list",
|
||||||
|
"detail": "views/record/detail",
|
||||||
|
"edit": "views/record/edit"
|
||||||
|
},
|
||||||
|
"recordViews": {
|
||||||
|
"list": "views/record/list",
|
||||||
|
"kanban": "custom:views/record/kanban"
|
||||||
|
},
|
||||||
|
"viewSetupHandlers": {
|
||||||
|
"record/detail": ["custom:handlers/my-detail-handler"]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
Views/RecordViews: Pfade zu JS-Views (z. B. "custom:views/account/detail" für custom View).
|
||||||
|
ViewSetupHandlers: Arrays von Handlern für dynamische Anpassungen (z. B. Feld-Updates).
|
||||||
|
Auslösen: Ändert Frontend-Rendering (z. B. neue View-Modi wie Kanban).
|
||||||
|
forum.espocrm.com
|
||||||
|
|
||||||
|
layouts/{EntityType}/detail.json (Format-Beispiel für Detail-View):
|
||||||
|
JSON
|
||||||
|
|
||||||
|
[
|
||||||
|
{
|
||||||
|
"label": "Overview",
|
||||||
|
"rows": [
|
||||||
|
[
|
||||||
|
{"name": "name"},
|
||||||
|
{"name": "assignedUser"}
|
||||||
|
],
|
||||||
|
[
|
||||||
|
{"name": "description"}
|
||||||
|
]
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"label": "Details",
|
||||||
|
"rows": [
|
||||||
|
[{"name": "createdAt"}]
|
||||||
|
]
|
||||||
|
}
|
||||||
|
]
|
||||||
|
|
||||||
|
Arrays von Panels (Objekte mit label und rows), rows sind Arrays von Zellen (Objekte mit name für Felder).
|
||||||
|
Auslösen: Ändert Feldanordnung in Views; unterstützt Parameter wie width, notSortable.
|
||||||
|
docs.espocrm.com
|
||||||
|
|
||||||
|
Spezielle Features:
|
||||||
|
APPEND: In Arrays als erstes Element einfügen, um bestehende Werte zu erweitern (z. B. options: ["APPEND", "NewOption"]).
|
||||||
|
layoutAvailabilityList: Array für Feld-Sichtbarkeit in Layouts (z. B. ["list", "detail"]).
|
||||||
|
layoutIgnoreList: Zu ignorierende Layouts.
|
||||||
|
|
||||||
|
3. Auslösen von Änderungen und Rebuild-Prozess
|
||||||
|
|
||||||
|
Was Änderungen auslösen:
|
||||||
|
Datei-Änderungen: Werden bei Merging berücksichtigt – rekursiv, also überschreiben Customs Core.
|
||||||
|
Datenbank-Effekte: Neue Felder/Links in entityDefs erzeugen Tabellen/Spalten (bei Rebuild).
|
||||||
|
Frontend-Effekte: clientDefs/Layouts ändern UI sofort nach Rebuild (z. B. neue Panels, Views).
|
||||||
|
Fehlerquellen: Ungültiges JSON oder falsche Typen können zu Fehlern führen (z. B. fehlende required-Felder).
|
||||||
|
Rebuild auslösen:
|
||||||
|
Manuell: Administration > Clear Cache & Rebuild (löscht Caches und merged Metadata neu).
|
||||||
|
Programmatisch (für KI): Die KI kann den Cache-Ordner löschen (data/cache/) oder ein PHP-Skript ausführen, das den Rebuild triggert (z. B. via EspoCRMs CLI: php command.php Rebuild). Keine direkte API, aber machbar mit Dateizugriff (z. B. exec("php rebuild.php")).
|
||||||
|
Effekt: Mergt alle Metadata, aktualisiert DB-Schema, cached Views. Ohne Rebuild bleiben Änderungen unsichtbar.
|
||||||
|
docs.espocrm.com
|
||||||
|
|
||||||
|
4. Best Practices für KI-Implementation
|
||||||
|
|
||||||
|
Workflow: 1. Datei lesen/parsen. 2. Modifizieren (z. B. Feld hinzufügen). 3. Validieren (JSON-Schema prüfen). 4. Speichern. 5. Rebuild triggern.
|
||||||
|
Sicherheit: Backups erstellen, Änderungen loggen. Vermeide Core-Änderungen.
|
||||||
|
Automatisierung: KI könnte Skripte generieren (z. B. Python mit json und os für Dateizugriff) oder direkt integriert werden (z. B. in einem Custom-Modul mit PHP-Aufrufen).
|
||||||
|
Grenzen: Keine out-of-the-box Automatisierung in Docs; Community erwähnt Skripte für Massen-Edits, aber nichts KI-spezifisch.
|
||||||
|
|||||||
Reference in New Issue
Block a user