710 lines
46 KiB
Text
710 lines
46 KiB
Text
....................... TASKS
|
|
|
|
We have here an ai agents workflow.
|
|
|
|
a big problem is document extraction. i uploaded a pdf file with a picture inside. in the database i see, that the document has 1 contents, "text" with a endline, marked as "is_extracted=True". it is missing the picture inside the pdf.
|
|
|
|
I would like to have the following implementation for files in a workflow:
|
|
|
|
How do documents arrive in the workflow:
|
|
a) user input with upload or drag&drop: the file shall be stored in the database (files) and its content stored in the workflow message as documents item with reference to the file_id in the database. all contents of the file will be stored as content items in the document item of the message object. according to the content type whey will be extracted as text or as base64 string (e.g. images). the document id will be a uuid and the document-source id the integer from the object in the database "files"
|
|
b) produces documents delivered by the agents: exactly the same like a)
|
|
|
|
the content provided to an agent will now be a document consisting of the content of all previous messages including the extracted content of the documents within the messages. the extracted content of the documents is produced for each content of the document:
|
|
- for text: An ai call with the extraction prompt delivers the text to be integrated
|
|
- for an image (it is available as base64 content) an ai call with the extraction prompt delivers the text to be integrated
|
|
|
|
Like this we have not anymore the problem, that file content is not found by the agents.
|
|
|
|
For code implementation I see a big opportunity to massively reduce code. To build basic methods to be used everywhere:
|
|
1. function "document_store_upload(message_id,filename,filepath...) --> function to store an uploaded or drag&drop document from the user and return the document object. This function does the steps for a) respectively b) like described above and identified the filetype
|
|
2. function "document_store_agent(message_id,filename,document_content,document_type...) --> function to store the produced document from the agent and return the document object. This function does the steps like described in section a) above
|
|
3. function "document_get_from_message()
|
|
|
|
Based on these 3 functions all operations can be done much more comfortable in the workflow, but also in connection with the ui (download file, copy file, preview file), because all references to the files are always ensured.
|
|
|
|
Can you analyze this idea?
|
|
What did I not yet consider, that would be relevant for the current code to adapt?
|
|
how big is the effort to have this logic implemented?
|
|
|
|
|
|
|
|
|
|
|
|
----------------------- OPEN
|
|
|
|
PRIO1:
|
|
|
|
ENV Variable setzen (extract from code) und config in .gitignore für example.env
|
|
|
|
Database to remove from backend
|
|
|
|
Integrate NDA Text as modal form - Data governance agreement by login with checkbox
|
|
|
|
workflow.css --> cleanup, later definition is newer
|
|
|
|
|
|
|
|
|
|
PRIO2:
|
|
|
|
backend: all object actions in interfaces generic for the objects in models for CRU-methods
|
|
|
|
frontend: no labels definition
|
|
|
|
sharepoint connector with document search, content search, content extraction
|
|
|
|
add connector to myoutlook
|
|
|
|
|
|
|
|
----------------------- DONE
|
|
|
|
|
|
Currently the webcrawler is always called for unclear prompts. Can you please add an agent for "Creative" or "knowledge" answers and select him rather than the webcrawler (meaning to adapt criteria for webcrawler, that he is only called for explicit web research or internet search).
|
|
|
|
The Creative Agent shall be selected for open questions or simple documentation topics, e.g. writing an email, write a birthday card, what to consider if going 1 year to usa, etc. He can also deliver documents. So to specify in his prompt, that it is clear what he delivers and how it it taken out for the next agent.
|
|
|
|
The exception for "poweron" keyword shall also be routed to this agent. This means, he is the one to answer the keyword "poweron". Like this you can please remove all "poweron"-specific code in the modules and integrate the answer for poweron in this "Creative" agent.
|
|
|
|
Please use the agentservice_base.py to create this agent (same template as for all other agents).
|
|
|
|
|
|
Modul "agentservice_agent_documentation.py": Bitte die Berichterstellung adaptiv zum Prompt machen. Bei einfachen Berichten eher eine Zusammenfassung, bei komplexen Berichten mit Kapiteln arbeiten.
|
|
|
|
|
|
PowerOn Message: Kannst Du einbauen, dass bei einem User Prompt, welcher in irgend einer Sprache fragt, "was PowerOn ist", dass dann die Rückmeldung is der Sprache der Anfrage etwas in dieser Art ist (bitte schön formulieren): *Ich bin glücklich, Teil der PowerOn Familie zu sein, welche sich dafür einsetzt, dass wir einander unterstüzzen und Gutes tun".
|
|
|
|
|
|
|
|
DOKUS
|
|
Doku des Systems für Investoren (Hi-level Struktur, Integrationsfähigkeit und Skalierbarkeit)
|
|
Doku des Systems für Code Integration
|
|
Release Notes (was kann das Teil)
|
|
Log der Anpassungen
|
|
Systemarchitektur (Grundsätze der Architektur, Komponenten und deren Aufbau)
|
|
|
|
|
|
|
|
|
|
# WORKFLOW EXECUTION
|
|
|
|
Die workflow execution soll so angepasst werden:
|
|
1. Der Workflow startet wie bisher bis und mit message initialisierung
|
|
2. Dann wird über den AI Call der Arbeitsplan erstellt, welcher als Resultat eine Liste der Aktivitäten liefert, die auszuführen sind. Pro Schritt ist strukturiert erfasst:
|
|
- Was ist im Schritt zu tun? Dies als AI Prompt, um anschliessend die Agenten für den Schritt zu definieren
|
|
- Welche Daten sind dazu nötig? Dies formuliert als AI Prompt an den Dateien-Manager
|
|
- Welches Resultat soll geliefert werden? - Strukturierte Angabe von Formatvorgaben (z.B. "Liste von Dateien","Text","JSON", "Tabelle", etc.)
|
|
3. Nun wird die Liste der Aktivitäten abgearbeitet. Pro Aktivität erfolgt dies:
|
|
- Agenten mit ihren Eigenschaften und dem Resultatformat zusammenstellen
|
|
- Mit AI Call festlegen, welche Agenten in welcher Reihenfolge nötig sind.
|
|
- Nun die Agenten schrittweise ausführen lassen. dazu diese schritte pro agent:
|
|
-- message object mit prompt und der angabe des letzten message objectes im workflow vorbereiten
|
|
-- Mit dem Hilfsmodul "agentservice_dataextraction.py" die nötigen Daten aus dem Workflow extrahierenund dem message object des agenten zufügen. Im Hilfsmodul noch das Objekt messages definieren.
|
|
-- agent liefert das resultat, welches als message object im workflow ergänzt wird.
|
|
4. Nun die Zusammenfassung der durch die agenten erstellten resultate für den User erstellen und ebenfalls als message im workflow speichern.
|
|
|
|
|
|
# CODE STRUKTUR
|
|
|
|
Aktuell hat es in jedem Modul und auch im Hauptmodul von agentservice* detaillierten Code drin. Kannst Du im gleichen Zug den Code aufräumen, dass "agentservice_workflow_manager" als master-modul nur funktionen aufruft und nicht noch details bearbeitet. so kann der workflow besser geführt werden.
|
|
|
|
Die Meldungen im "_add_log()" sowie die Logger-Mledungen sind unübersichtlich und helfen kaum zur Analyse. Bitte diese Meldungen anhand des Workflows strukturieren und auch die Moderator-Anweisungen (zusammengefasst im _add_log und mit den parametern (lange texte gekürzt) im logger) ausgeben, damit eine Fehlersuche einfacher ist.
|
|
|
|
Bitte Hilfsfunktionen, welche überall immer wieder verwendet werden, in ein utility modul auslagern. Als Idee Dinge wie
|
|
- Class mit Methoden zum lesen, schreiben, extrahieren von messages im workflow inklusive Typenkonversion von Dict in str. Dass ich z.B. schreiben kann (nur als idee, gibt eventuell schlauere funktionen): workflow(id).documents.extract_by_prompt(prompt).to_str()
|
|
- Bitte analysiere den code, was an Funktionen Sinn macht
|
|
|
|
Allenfalls noch andere Themen, die helfen, den Code zu vereinfachen. Das Ziel soll es sein, dass der Workflow und die Agentencodes nicht jedes Detail immer codiert haben müssen mit immer wieder fehlerabfangroutinen, sondern dass wie auf vordefinierte module zugreifen können und diese durchgängig nutzen. damit soll der code massiv verkürzt werden.
|
|
|
|
|
|
|
|
|
|
|
|
# DATEIEN EINLESEN
|
|
|
|
Wenn eine Datei/File (in der datenbank ein Dokument) als Text lesbar ist (txt, csv, html, Text in Pdf etc.), dann wird der text des dokumentes direkt ausgelesen und als DocumentContent in der DB erfasst --> is_extracted=True. Wenn ein Dokument nicht als Text lesbar ist (Bilder, Videos, Bilder in PDF etc.), dann wird der text des entsprechenden DocumentContent nicht extrahiert, also is_extracted=False. (hinweis: Die extraktion findet dann erst im workflow mit einem prompt statt.)
|
|
|
|
|
|
# AGENTEN
|
|
|
|
In jedem Agenten-Profil ein Attribut ergänzen, welches spezifisch angibt, in welchem Format der Agent das Resultat zurückliefert (z.b. "DocumentID" oder "Text" oder "List of ..." etc.).
|
|
|
|
|
|
# HILFSFUNKTIONEN
|
|
|
|
1. data_extraction(prompt) --> messages: ai call durchführen mit einer liste aller dateien mit ihren metadaten und aller messages im workflow. mit dem prompt prüfen, welche inhalte von welchem datenobjekt erforderlich sind. das resultat soll eine liste sein, welche pro datenobjekt den prompt enthält, um die nötigen daten zu extrahieren. diese liste abarbeiten (falls ein dokument den inhalt nicht extrahiert hat, diesen nun mit der entsprechenden funktion extrahieren; bild-extraktion ist bereits als funktion verfügbar) und die extrahierten daten mit ihren kontext-informationen als strukturiertes text-object zurückgeben (metadaten mit extrahierten inhalten)
|
|
|
|
|
|
# ZUSAETZLOCHE AGENTEN
|
|
|
|
NEU: Der Filecreator kann dies tun, welche relevant für seine Fähigkeiten sind:
|
|
Datei erstellen --> Document object in der Datenbank mit dem mitgelieferten inhalt und datentyp erzeugen und die id zum Datenobjekt zurückliefern
|
|
|
|
|
|
Implementieren: Coder
|
|
Dieser soll python code generieren und als Parameter die verfügbaren Funktionen im Umsystem (z.b. für Files laden und speichern) (als Erweiterung im Beispiel soll pro Funktion angegeben werden, welche Parameter und welches Resultat-format, hier ein geeigneter vorschlag von dir bitte). Den Code anschliessend ausführen, so wie im Code Beispiel "_code_exec_temp.py". Dann das Resultat zurückgeben.
|
|
|
|
|
|
|
|
|
|
Workflow module refactored
|
|
|
|
Summary of Changes
|
|
I've refactored the workflow module into separate modules with clear responsibilities:
|
|
1. workflow.js - Main Coordinator
|
|
|
|
Acts as the central controller for the workflow functionality
|
|
Coordinates interactions between all other modules
|
|
Manages the workflow lifecycle (starting, stopping, resetting)
|
|
Contains minimal direct DOM manipulation
|
|
Maintains the core workflow state
|
|
|
|
2. workflow_ui.js - UI Rendering and Layout
|
|
|
|
Handles all DOM rendering functionality
|
|
Manages layout changes (resize, expand/collapse)
|
|
Sets up UI-related event listeners
|
|
Updates visual status (buttons, statistics)
|
|
Completely separates UI concerns from data and business logic
|
|
|
|
3. workflow_data.js - Data Management
|
|
|
|
Handles all API communication (via utils.js)
|
|
Centralizes state management for workflow data
|
|
Processes data from API responses
|
|
Manages file references and retrieval
|
|
Handles data statistics tracking
|
|
|
|
4. workflow_features.js - Feature Modules
|
|
|
|
Manages chat functionality
|
|
Handles file upload/processing
|
|
Controls log management
|
|
Processes user input
|
|
Encapsulates drag-and-drop functionality
|
|
|
|
5. workflow_utils.js - Helper Functions
|
|
|
|
Contains shared utility functions
|
|
Text formatting helpers
|
|
File-related utility functions
|
|
Error/dialog management
|
|
Data validation and conversion
|
|
|
|
|
|
|
|
* Refactoring-Auftrag: Workflow-System-Überarbeitung *
|
|
|
|
## Übersicht
|
|
Dieser Auftrag umfasst eine vollständige Überarbeitung des Workflow-Ablaufs sowohl im Frontend als auch im Backend. Das Ziel ist eine Vereinfachung der Benutzeroberfläche, bessere Modularisierung des Codes und Optimierung der Datenhaltung, sowie Hinzufügen einer Löschfunktion für einzelne Nachrichten zur Datenmengenbegrenzung.
|
|
|
|
## Anforderungen Frontend
|
|
|
|
### 1. UI-Elemente entfernen
|
|
- Vollständige Entfernung der Sektion "Prompt eingeben"
|
|
- Entfernung aller Buttons im Bereich "Ausführung & Ergebnisse", mit Ausnahme des "Workflow stoppen"-Buttons, der nur während eines aktiven Workflows sichtbar sein soll
|
|
- Der "Workflow stoppen"-Button soll automatisch ausgeblendet werden, sobald eine Benutzereingabe angefordert wird
|
|
- Entfernung der Anzeige des ausgewählten Workspaces in der index.html
|
|
|
|
### 2. User-Input-Modul auslagern
|
|
- Extraktion aller Funktionen zur Benutzereingabe aus "workflow.js" in ein neues separates Modul "workflow_userinput.js"
|
|
- Das neue Modul soll sowohl für den initialen Prompt als auch für alle weiteren Benutzerantworten im Workflow verwendet werden
|
|
|
|
### 3. Funktionalität User-Input-Modul
|
|
Das neue "workflow_userinput.js" Modul soll folgende Funktionen enthalten:
|
|
- Erkennung, wann eine Benutzereingabe erforderlich ist (initial und wenn der User-Agent aufgerufen wird)
|
|
- Auswahl vordefinierter Prompts ermöglichen
|
|
- Datei-Upload und Drag & Drop Funktionalität
|
|
- Senden des Prompts an das Backend mit der workflowid, falls vorhanden
|
|
- Implementation einer Löschfunktion ("x") für jede Nachricht und angehängte Datei im Chat-Protokoll
|
|
|
|
### 4. Nachrichtenlöschfunktion
|
|
- Jede Nachricht im Multi-Agent Chat Protokoll erhält einen "x"-Button zum Löschen
|
|
- Löschfunktion soll auch für Dateien innerhalb einer Nachricht implementiert werden
|
|
- Nahtlose API-Integration mit dem neuen DELETE-Endpunkt für Nachrichten
|
|
|
|
## Anforderungen Backend
|
|
|
|
### 1. Route "workflow.py"
|
|
- Reduzierung auf minimale Routing-Funktionalität
|
|
- Verlagerung aller Implementierungslogik in den "agentservice_workflow_manager"
|
|
- Hinzufügen eines neuen Endpunkts: `DELETE /api/workflows/{workflow_id}/messages/{message_id}`
|
|
|
|
### 2. Workflow-Manager-Logik
|
|
Überarbeitung des "agentservice_workflow_manager" mit folgender Ablauflogik:
|
|
1. Workflow-Initialisierung:
|
|
- Bei neuem Workflow: Initialisierung mit leerem Messages-Objekt
|
|
- Bei bestehendem Workflow: Übernahme des vorhandenen Messages-Objekts
|
|
|
|
2. Message-Objekt-Verwaltung:
|
|
- Starten eines neuen Message-Objekts für jede Interaktion
|
|
- Vollständige Nutzung des Datenmodells aus "lucydom_model.py"
|
|
- Korrekte Speicherung in der Datenbank
|
|
|
|
3. Dateivorbereitung:
|
|
- Erstellung von Datei-Kontexten und Integration ins neueste Message-Objekt
|
|
- Extraktion und Speicherung von Dateiinhalten
|
|
- Formatierung der Daten für die Agenten-Verarbeitung
|
|
|
|
4. Agent-Workflow:
|
|
- Initialisierung verfügbarer Agenten einschließlich User-Agent
|
|
- Implementierung der Moderator-Entscheidungslogik (bereits implementiert) -> entweder wird eine liste von agenten verarbeitet (OHNE User agent!), oder der user agent aufgerufen.
|
|
4a) - Ausführung der Agenten in der festgelegten Reihenfolge
|
|
4b) - Abschluss mit User-Agent und Prompt-Aufforderung (Anmerkung: die wofkflow id mitgeben, damit nach dem senden der user antwort im frontend der workflow weitergeführt wird bei Punkt 1. Aber im Backend ist es hier fertig)
|
|
|
|
5. Nachrichten-Löschfunktion:
|
|
- Implementierung der Löschlogik für einzelne Nachrichten
|
|
- Vollständige Entfernung der Nachrichtendaten auch aus dem Backend-Speicher
|
|
|
|
## Betroffene Dateien
|
|
|
|
### Frontend-Dateien:
|
|
1. `workflow.js` - Umfassende Überarbeitung und Entfernung von User-Input-Funktionalität
|
|
2. `workflow_userinput.js` - Neue Datei für die ausgelagerte User-Input-Funktionalität
|
|
3. `index.html` - Entfernung der nicht mehr benötigten UI-Elemente und Integration des neuen Moduls
|
|
4. `main.js` - Anpassungen für die geänderte Modularität
|
|
5. `globalState.js` - Ggf. Anpassungen für die geänderte Workflow-Struktur
|
|
6. `utils.js` - Erweiterung um die neue DELETE-Funktion für Nachrichten
|
|
|
|
### Backend-Dateien:
|
|
1. `workflows.py` - Vereinfachung und Hinzufügen des neuen DELETE-Endpunkts
|
|
2. `agentservice_workflow_manager.py` - Umfassende Überarbeitung der Workflow-Logik
|
|
3. `lucydom_interface.py` - Erweiterung um Methoden zum Löschen von Nachrichten
|
|
4. `agentservice_agent_user.py` - Anpassungen für das neue User-Input-Handling
|
|
|
|
## Fehlerbehandlung
|
|
- Frontend:
|
|
- Konsistente Fehlerbehandlung für alle API-Aufrufe implementieren
|
|
- Benutzerfreundliche Fehlermeldungen bei fehlgeschlagenen Operationen anzeigen
|
|
- Status-Indikatoren während laufender Operationen (z.B. Löschen von Nachrichten)
|
|
|
|
- Backend:
|
|
- HTTP-Statuscode 404 zurückgeben, wenn eine zu löschende Nachricht nicht gefunden wird
|
|
- Sicherstellen, dass alle Workflow-Operationen Transaktionssicherheit bieten
|
|
- Ausführliche Logging-Funktionalität für Fehlerdiagnose
|
|
|
|
## Richtlinien zur Codequalität
|
|
- Clean Code-Prinzipien beachten (DRY, SOLID)
|
|
- Konsistente Benennung und Dokumentation
|
|
- Entfernung ungenutzter Funktionen und Code-Teile
|
|
- Ausreichende Kommentierung für komplexe Logik
|
|
|
|
## Zusätzliche Hinweise
|
|
- Daten dürfen ohne Bedenken gelöscht werden
|
|
- Keine Übergangsstrategie erforderlich, System startet neu
|
|
- Keine Bestätigungsdialoge für das Löschen von Nachrichten erforderlich
|
|
- Keine speziellen Berechtigungsanforderungen für das Löschen von Nachrichten
|
|
|
|
|
|
|
|
|
|
*WORKFLOW*
|
|
|
|
ich habe das backend komplett angepasst mit dem workflow und dem datenmodell. die wichtigsten anpassungen sind das datenmodell für workflow und messages. Nun muss das Frontend entsprechend angepasst werden.
|
|
|
|
|
|
hier der ablauf des workflows im backend zur information:
|
|
|
|
1. Der User kann (A) einen neuen Workflow starten oder (B) bei einem bestehenden Workflow einen user Input liefern. Die Endpunkte liegen bei.
|
|
. Varinate (A): Der User sendet einen Prompt mit Dateien für einen neuen Workflow. Damit wird ein neuer leerer Workflow erstellt
|
|
. Varinate (B): Es erfolgt ein User Input mit allenfalls Dateien zu einem bestehenden Workflow. Als Input wird ein messages objekt geliefert. Der workflow Status wird auf "running" gesetzt.
|
|
|
|
2. Message Initialisierung: Das letzte Message Objekt wird abgeschlossen (falls eines existiert) und ein neues Message Object erstellt. Dieses wird nun komplettiert.
|
|
3. Dateivorbereitung: Datei-Kontexte werden erstellt und ins neuste Message objekt abgefüllt. Dateiinhalte werden gelesen, extrahiert und ins message objekt abgefüllt. Daten werden für die Verarbeitung durch die Agenten formatiert
|
|
4. Agent-Initialisierung: Die verfügbaren Agenten werden geladen inklusive der user agent.
|
|
5. Moderator-Entscheidung
|
|
6. Agent-Ausführung, bis am Schluss der User aufgerufen wird, um einen Input zu geben.
|
|
7. Nun ist der "User Agent" an der Reihe. Der user Input hat immer obendran die Frage, die dem User gestellt wird. der user input hat die workflow id dabei.
|
|
hier ist der workflow beendet. wenn der user seine antwort sendet, geht es weiter bei punkt 1 Variante (B)
|
|
|
|
Dies zusätzlich anzupassen:
|
|
|
|
- Der initiale Prompt mit File-Upload ist gleichzeitig auch der Prompt, der dem User angeboten wird, wenn im Chat ein Input von ihm nötig ist. Dieses Eingabefeld soll an die Stelle verschoben werden, wo aktuell der User-Dialog angezeigt wird bei "wait for user". So gibt der User die Daten immer am gleichen Ort ein.
|
|
|
|
- Für den File Upload sollen zwei Methoden möglich sein.
|
|
-- a: Upload-Button direkt unten am Prompt. Jedes geladene File wird dann als kleines Icon mit dem Filenamen unter dem Prompt ergänzt mit einem "x", damit es wieder gelöscht werden kann, wenn nicht benötigt. Wenn Text aus dem File extrahiert werden konnte, so ist das Feld mit dem Dateinamen grün, sonst rot. Ist Dir klar, wie Du diese Information abfragen kannst? - Wenn der User den Prompt absetzt, wird dieser über das Backend anschliessend in die Resultate geliefert. Du musst dies nicht im Frontend machen, sonst haben wir es doppelt.
|
|
-- b: Drag & Drop: Ein File kann in den Prompt-Bereich gezogen werden, dann wird es auch hochgeladen.
|
|
|
|
- Das Auswahlfenster für vordefinierte Prompts soll direkt über dem Eingabefeld für den Benutzer sein.
|
|
|
|
- Die Buttons zur Steuerung des Workflows sollen oben am Bereich "Ausführung & Ergebnisse" verschoben werden.
|
|
|
|
- Der Bereich "1. Dateien auswählen" entfällt somit, da integriert bei mUser Prompt.
|
|
|
|
- Der Bereich "2. Promot eingeben oder auswählen" entfällt auch
|
|
|
|
- Der Bereich "3. Agenten auswählen" entfällt auch
|
|
|
|
- Resultateintrag: Jeder Eintrag im Resultat-Log hat zuoberst Icons mit den Files, welche die Agenten zurückliefern, dann den Text dazu. Jedes Icon eines Files hat die Buttons "Download" und "Copy" (für Clipboard") und "Vorschau"
|
|
|
|
- Damit entfällt der Bereich "Workflow-Konfiguration" komplett. Die beiden Bereiche sollen aber beibehalten werden, einfach mit anderem Inhalt. Im aktuellen Bereich "Workflow-Konfiguration" soll neu der Bereich "Ausführung & Ergebnisse" drin sein. Im aktuellen Bereich"Ausführung & Ergebnisse" soll NEU der Bereich "Dateivorschau" hinkommen. Dort kann eine von den Agenten gelieferte Datei (siehe Punkt "Resultateintrag" zuvor) als "Vorschau" angeschaut werden. Oben rechts hat es zwei Icons "Download" und "Copy" (für Clipboard).
|
|
|
|
* WEITERE ANPASSUNGEN *
|
|
- Die Objekte "agents" und "workspaces" sind eliminiert und zu entfernen. Somit fallen auch die entsprechenden Navigationseinträge weg und alle Funktionen im Zusammenhang mit Workspaces. Es gibt keine Workspaces mehr.
|
|
|
|
|
|
Kannst Du vor der Umsetzung prüfen, ob Du alle nötigen Dateien und Informationen hast und mir zusammenstellen, was Du machen wirst?
|
|
|
|
|
|
|
|
Ich möchte den agentenchat workflow ändern. kannst du mir bitte dazu in einem ersten schritt das backend anpassen.
|
|
|
|
1. das datenobjekt *workspaces" und "agents" wird nicht mehr benötigt, und kann entfernt werden. Der user arbeitet mit einzelnen workflows. Agenten sind systemseitig fix definiert.
|
|
|
|
2. alle workflow router endpunkte bleiben bestehen, wie sie sind
|
|
|
|
3. Neue Objektstruktur für den workflow ablauf:
|
|
|
|
workflow =
|
|
{
|
|
// Core workflow properties
|
|
"id": "workflow_uuid",
|
|
"name": "Analysis Workflow",
|
|
"mandate_id": 123,
|
|
"user_id": 456,
|
|
"status": "running", // "running", "failed", "stopped"
|
|
"started_at": "2025-03-29T14:15:00.000Z",
|
|
"last_activity": "2025-03-29T14:45:00.000Z",
|
|
"current_round": 1,
|
|
"waiting_for_user": false,
|
|
|
|
// Performance statistics (sum)
|
|
"data_stats": {
|
|
"total_processing_time": 3.9,
|
|
"total_token_count": 857,
|
|
"total_bytes_semt": 1026323,
|
|
"total_bytes_received": 4200,
|
|
}
|
|
|
|
// Messages array - main conversation history with structured message objects
|
|
"messages": [],
|
|
|
|
// Logs
|
|
"logs": [
|
|
{
|
|
"id": "log_uuid1",
|
|
"message": "Workflow started",
|
|
"type": "info",
|
|
"timestamp": "2025-03-29T14:15:00.000Z"
|
|
}
|
|
]
|
|
|
|
}
|
|
|
|
"messages": [
|
|
{
|
|
// Core message properties
|
|
"id": "msg_uuid", // Unique identifier for each message
|
|
"workflow_id": "workflow_uuid", // Reference to the parent workflow
|
|
"parent_message_id": "msg_previous_uuid", // Reference to message being responded to
|
|
"started_at": "2025-03-29T14:30:00.000Z", // Single timestamp for message creation
|
|
"finished_at": "2025-03-29T14:30:00.000Z", // Single timestamp for message closing, when next message is created
|
|
"sequence_no": 1, // Optional, but useful for ordering within workflow
|
|
|
|
// Status information
|
|
"status": "completed", // message status: "pending", "processing", "completed", "failed"
|
|
|
|
// Role instead of agent information
|
|
"role": "system", // "system", "user", "assistant" - who created this message
|
|
|
|
// Metadata for statistics and accounting
|
|
"data_stats": {
|
|
"processing_time": 2.5, // Time taken to generate in seconds
|
|
"token_count": 1205, // Token count (for AI models)
|
|
"bytes_sent": 4096, // Data sent to generate this message
|
|
"bytes_received": 8192, // Data received
|
|
}
|
|
|
|
// Documents section - includes prompt and all referenced files
|
|
"documents": [
|
|
{
|
|
// Document metadata
|
|
"id": "doc_uuid",
|
|
"source": {
|
|
"type": "prompt", // "prompt", "file", "clipboard"
|
|
"path": "/full/path/to/file.txt", // Storage path (for files)
|
|
"name": "display_filename.txt",
|
|
"size": 1024, // Size in bytes
|
|
"lines": 42, // Line count (for text files)
|
|
"content_type": "text/plain", // MIME type
|
|
"upload_date": "2025-03-29T14:30:00.000Z"
|
|
},
|
|
|
|
// Document contents (can have multiple parts)
|
|
"contents": [
|
|
{
|
|
"label": "Main Content", // Optional label
|
|
"type": "text", // "text", "image", "chart", etc.
|
|
"text": "The actual text content",
|
|
"is_extracted": true // Flag if this is extracted from original file
|
|
}
|
|
]
|
|
}
|
|
],
|
|
|
|
}
|
|
]
|
|
|
|
|
|
4. Die Schritte in einem Workflow (neu) - bitte den code revidieren und alle unnötigen teile entfernen.
|
|
|
|
4.1 Der User kann (A) einen neuen Workflow starten (Enpunkt api/workflows/run) oder (B) bei einem bestehenden Workflow einen user Input liefern (Endpunkt /api/workflows/{workflow_id}/user-input). Mit beiden Varianten soll bei execute_workflow() gestartet werden.
|
|
|
|
. Varinate (A): Der User sendet einen Prompt mit Dateien für einen neuen Workflow. Damit wird ein neuer Workflow mit execute_workflow() erstellt, aber noch ohne message objekt. Als Input wird ein messages objekt geliefert. Initialer workflow Status wird auf "running" gesetzt.
|
|
|
|
. Varinate (B): Es erfolgt ein User Input mit allenfalls Dateien zu einem bestehenden Workflow. Als Input wird ein messages objekt geliefert. Der workflow Status wird auf "running" gesetzt.
|
|
|
|
4.2.- Message Initialisierung: Das letzte Message Objekt wird abgeschlossen (falls eines existiert) und ein neues Message Object erstellt. Dieses wird nun komplettiert.
|
|
|
|
4.3- Dateivorbereitung: Datei-Kontexte werden mit prepare_file_contexts() erstellt und ins neuste Message objekt abgefüllt. Dateiinhalte werden mit read_file_contents() gelesen, extrahiert und ins message objekt abgefüllt.
|
|
Daten werden für die Verarbeitung durch die Agenten formatiert
|
|
|
|
4.4 Agent-Initialisierung: Die verfügbaren Agenten werden mit initialize_agents() aus dem Modul "agentservice_part_agents" geladen inklusive der user agent.
|
|
|
|
4.5. Moderator-Entscheidung: Es gibt keinen agenten "Moderator". Anhand des des neusten Message Objektes und den Profilen der verfügbaren Agenten wird mit dem OpenAI Call abgefragt, wie die Anfrage gelöst werden soll. Als Resultat-Format soll ein json-objekt vorgegeben werden, welcher agent welchen job (=Prompt für diesen) ausführen soll, mit welchen antworten und welchen datenobjekten. dazu sind keine weiteren subfunktionen nötig. das antwortformat soll so vorgegeben werden, dass zwingend pro auftrag verfügbare agenten rückgemeldet werden. Das Agentenset soll immer entweder nur der User oder nur system-agenten sein. somit ist das antwortformat eine liste mit agenten und deren aufträgen.
|
|
|
|
4.6. Agent-Ausführung: Falls eine agentenliste zürückgegeben wird (und nicht der user), werden die Agenten in der angegeben Sequenz aufgerufen werden, um ihren Beitrag zu liefern. Agent-Antworten werden mit create_agent_result() ins message objekt integriert, die verschiedenen files separiert. Als nächstes wird mit den gelieferten Antworten der Agenten (nur dieser Teil, nicht die früheren Nachrichten) über den OpenAI Call eine Zusammenfassung erstellt und als Input-Text dem user Agenten übergeben, welcher nun als nächsten Agenten ausgewählt wird. Der ablauf wird gestoppt, wenn der Workflow manuell mit stop_workflow() gestoppt wird (status auf "stopped"), oder ein Fehler auftritt (status auf "failed").
|
|
|
|
4.7. Nun ist der "User Agent" an der Reihe. Der Workflow-Status wird auf "waiting_for_user" gesetzt. Der ganze Teil mit _process_user_input() etc. entfällt. Nach der Benutzereingabe wird der Workflow nicht mit _continue_workflow_after_user_input() fortgesetzt, sondern regulär wieder bei Punkt 4.1 über den Zweig (B).
|
|
|
|
4.8. Protokollierung: Jeder Schritt wird mit _add_log() protokolliert. Logs werden im Workflow-Objekt gespeichert.
|
|
|
|
4.9. Hier endet der Workflow regulär, bis der User eine neue Anfrage macht. Das heisst, es benötigt keine Moderatoren-Checks mehr, keine maximale Rundenzahl. Der Workflow wird mit save_workflow_results() gespeichert.
|
|
|
|
|
|
5. Fortlaufendes Polling: Der Client kann den Workflow-Status mit get_workflow_status() abfragen. Protokolle können mit get_workflow_logs() abgerufen werden. Ergebnisse können mit get_workflow_results() abgerufen werden.
|
|
|
|
|
|
6. agents: Die verfügbaren Agenten werden mit initialize_agents() aus dem Modul "agentservice_part_agents" geladen. die agentendaten, werden in separaten dateien abgelegt, damit dies wartbar ist. Es werden diese agenten-module vorbereitet:
|
|
.agentservice_agent_user
|
|
.agentservice_agent_coder
|
|
.agentservice_agent_analyst
|
|
.agentservice_agent_webcrawler
|
|
.agentservice_agent_sharepoint
|
|
.agentservice_agent_documentation
|
|
Pro agent werden diese attribute definiert:
|
|
.name
|
|
.description
|
|
.capabilities
|
|
Jeder Agent hat dann seine eigenen Funktionen in seinem File integriert, die er benötigt.
|
|
|
|
7. Konnektorenbereinigung:
|
|
- Alle Konnectoren in einen subfolder "connectors" verschieben, d.h. alle files mit "connector_..."
|
|
- Die zwei Konnektoren "connector_aichat..." so umschreiben, dass sie daten als Input im format des messgaes Objekt gemäss Punkt 3 als input übernehmen und auch wieder zurückgeben.
|
|
|
|
8. geänderte speicherng von workflows: Bitte den code so anpassen, dass workflows als datenbankobjekte gespeichert werden, analog so wie prompts.
|
|
D.h. die routes für "workflows" ergänzen mit "GET /api/workflows", "PUT /api/workflows/{workflow_id}", "DELETE /api/workflows/{workflow_id}"
|
|
Die Route "POST /api/workflows/run" umbenennen in "POST /api/workflows"
|
|
Die Route "/api/workflows/{workflow_id}/results" umbenennen in "GET /api/workflows/{workflow_id}"
|
|
Sinngemäss alle module anpassen und die Datenbankklassen vorbereiten.
|
|
|
|
Die Buttons "Workflow starten" und "Zurücksetzen" haben keinen Rahmen. Ist hier ggf. die Style Class falsch oder nicht appliziert?
|
|
|
|
Anpassung des Visuals "Ausführung & Ergebnisse":
|
|
- Das Ausführungsprotokoll so belassen. Einen Button rechts von den anderen zwei Buttons (alle anzeigen / Details zuklappen) ergänzen, für dies mit dem Ausführungsprotokollfenster: toggle function collapse and restore
|
|
- Die Bereiche "Multi-Agent-Chat" und "Ergebnisse" machen so keinen Sinn. Diese beiden Bereiche bitte zusammenlegen in einen grossen Bereich mit dem Namen "Multi-Agent Chat Area". Dort laufend die Messages der Agenten in einer HTML-Ansicht der Messages protokollieren. Jeweils der Name des Agenten im Titel und darunter seine Message. Die letzte Message soll aufgeklappt sein, alle früheren sollen jeweils zugeklappt sein, aber durch den User soll ein toggle pro Message möglich sein, um die Details zu sehen.
|
|
|
|
|
|
Kannst Du den Ablauf des Agenten-Chats wie folgt optimieren:
|
|
- Bei jedem Chat einen "User Agent" mit dem Namen des eingelogten Benutzers ergänzen. Wenn etwas im Chat nicht klar ist, oder zusätzliche Informationen nötig sind, so fragt er den User Agent. Auch bevor er den Chat beendet, fragt er den User Agent, ob dieser einverstanden ist.
|
|
- Wenn der User Agent eine Anfrage erhält, so kann er direkt unter der Chat History im Bereich ereiche "Multi-Agent-Chat" seinen Text in einem mehrzeiligen Textfeld erfassen. Er kann auch zusätzliche Files hochladen. Wenn er "Enter" drückt, werden die zusätzlichen Daten mit den ergänzten Files zur Message ergänzt, das Eingabefenster verschwindet wieder und der Moderator führt den Chat fort. Immer nach einer Benutzereingabe startet der Zähler wieder bei Runde 1.
|
|
|
|
Statistik ergänzen: Kannst Du bitte rechtsbündig neben dem Titel des "Ausführungsprotokolls" laufend die Statistik nachführen, wieviele kBytes (kB) Daten über den Connector zum AI-Modell gesendet wurden (dies ist die Datengrösse des Message-Objektes) und wieviele kB an Messages zurückgeliefert wurden. Diese angabe pro Workflow-Durchlauf, also immer beim Start eines neuen Workflows wird der Zähler auf 0 gesetzt. In diesem Format: "^ 250k v 1'250k ", v und ^ durch Pfeile ersetzt.
|
|
|
|
|
|
In den Einstellungen des Frontends soll die Sprache des aktiven benutzers gemäss den Listenoptionen in den "...model.py" angepasst werden können. die sprache gilt dann auch für die Attributnamen in einem Formularfeld im "generic-entity.js". eine sprachänderung zieht somit eine anpassung des Users über das API nach sich, indem die Sprache in der Datenbank angepasst wird.
|
|
|
|
kannst du die ausführungsprotokollierung anpassen? das protokoll soll laufend anzeigen, welcher assistent welches resultat produziert hat und welcher assistent aktuell am arbeiten ist. Prozentzahlen sind keine nötig, diese machen keinen sinn. das polling so beibehalten, aber wenn keine neuen Daten bereitstelen, dann beim letzten Timestamp einfach laufend "." ergänzen, bis die nächste Meldung ausgegeben wird. hast du alle daten, um dies im frontend und im backend anzupassen?
|
|
|
|
Im Ausführungsprotokoll pro Eintrag nur den Titel zeigen und die Details zwar ins Protokoll nehmen, aber ausblenden. Der Benutzer kann dann im Protokoll die zugeklappten Texte aufklappen, um die gewünschten Details gezielt zu sehen.
|
|
|
|
Im Front-End beim Workflow-Modul bitte das Ausführungsprotokoll-Fenster dynamisch in der Grösse anpassbar machen. in der Breite und der Höhe. Dasselbe für das Ergebnis-Fenster. Zudem die Ansicht so gestalten, dass die Fensterteile "Workflow-Konfiguration" und "Ausführung & Ergebnisse" ein- und ausgeblendet werden können, damit jeweils ein Teil die komplette Arbeitsfläche verwenden kann, weil dort viel Text stehen wird. Dies ist für den Benutzer besser.
|
|
|
|
nun zu diesem zentralen modul. ich hätte gern, dass die daten als tabellen dargestellt und bearbeitet werden können. für view, add, modify, delete jeweils icon pro datensatz ganz links und zuoberst im header ein "new item" symbol oder text, mach einen vorschlag.
|
|
|
|
ist es möglich, eine checkbox pro datensatz zu machen, um mehrere elemente auszuwählen und oben an der tabelle icons zu haben für mehrfach delete?
|
|
|
|
die tabelle soll nach allen feldern gefiltert und sortiert werden können
|
|
|
|
kannst du bitte den code so anpassen, dass main.js die seitenmodule im Anhang dynamisch erst dann lädt, wenn die entsprechende seite in der navigation aufgerufen wird?
|
|
|
|
dann bitte main.js modularisieren, sodass dort nur funktionsaufrufe auf sub-module ausgeführt werden. das navigationsmenu nach "navigation.js" auslagern. den aufbau und betrieb des aktuellen workspaces im main.js drin lassen.
|
|
|
|
Der aktuelle Hauptbereich mitt der Auswahl des workspaces, den zugehörigen Agenten etc ist neu ein Objekt, welches in der "mainView" dargestellt werden kann. Auch andere Objekte können in der mainView dargestellt werden und haben jeweils ihre spezifischen Paramter dazu, wie nachfolgend erklärt.
|
|
|
|
im main.js wird ein globales objekt aller elemente erstellt, welche in der navigation enthalten sein sollen und welches die grundlage für alle funktonsaufrufe beinhaltet. damit gibt es dann im index.html keine details mehr zu den navigationen.
|
|
|
|
|
|
diese attribute hat das globale objekt:
|
|
|
|
globalState
|
|
.objects
|
|
.user
|
|
.mainView
|
|
|
|
Hier die Spezifikation der Objekte.
|
|
|
|
.objects[...]: hat eine liste von objekten, welche im mainScreen geladen werden können. Diese Attribute pro Objekt bitte gemäss den heutigen js files im anhang sinngemäss übernehmen:
|
|
- label: Liste des Labelnamen in den verschiedenen sprachen (default, en, fr...)
|
|
- modulName: string; dieser wird verwendet für die objektklasse "js/modules/{modulname}.js" und für die html-komponente dazu "modules/part-{modulname}.html und für die calls ans backend /api/{modulname}/..."
|
|
- icon: Icon vor dem Menupunkt
|
|
- navigationContext: "left" für agents, data, prompts, users, mandates, workspaces ; "top" für sprachauswahl, logout
|
|
- isVisible (hier wird z.b. users und mandates nur angezeigt, wenn auch die berechtigung dafür besteht)
|
|
- isActive: Wenn der Menupunkt ausgewählt ist
|
|
- navigationContext: diese Optionen, wo ein Objekt ins Menu genommen wird:
|
|
--"nav_left" für agents, data, prompts, users, mandates, workspaces
|
|
--"nav_top" für sprachauswahl, logout
|
|
- navigationActionType: Was passiert, wenn auf das Menu geklickt wird. Diese Optionen:
|
|
--"module": Standard-Menu button. Es wird ein Modul in die mainView geladen. Das Modul wird erst geladen und mit den Daten initiiert, wenn der Menupunkt ausgewählt wird
|
|
--"group_open": Gruppenheader; Start einer neuen Gruppe; alle nachfolgenden Objekte der Liste sind in dieser Gruppe integriert. Die Gruppe kann im Menu auf- und zugeklappt werden. Initial Gruppe open, alle Menupunkte sichtbar
|
|
--"group_collapsed": Gruppenheader; Start einer neuen Gruppe; alle nachfolgenden Objekte der Liste sind in dieser Gruppe integriert. Die Gruppe kann im Menu auf- und zugeklappt werden. Initial Gruppe collapsed.
|
|
|
|
.user: Attribute zum aktiven user
|
|
- mandate_id
|
|
- user_id
|
|
- username
|
|
- full_name
|
|
- language (default, en, fr, ...)
|
|
- isAdmin
|
|
- isSysAdmin
|
|
- lastWorkspaceId: Id des zuletzt genutzten Workspaces - aktuell "null"
|
|
- session: aktuell null und nicht verwendet
|
|
|
|
.mainView: enthält immer die aktuellen Attribute, welche die Seite in der mainView nutzen kann
|
|
- currentWorkspace: objekt des aktuell ausgewählten Workspaces
|
|
- availableFiles[]: list of objects
|
|
- availableAgents[]: list of objects
|
|
- availablePrompts[]: list of objects
|
|
- currentWorkflowId: id
|
|
|
|
|
|
kannst du bitte part-workflow.html und workflow.js mit dem dynamischen Multi-Agent Chat aktualisieren, welcher im backend angepasst wurde und im Ausführungsprotokoll die Details eines laufenden Chats mit aufklappbaren Texten ergänzen. Das Ausführungsprotokoll-Fenster dynamisch in der Grösse anpassbar machen.
|
|
|
|
Css aufräumen und konsolidieren für gemeinsame Klassen mit allen html und js parallel
|
|
|
|
Admin Seite mit CRUD für User Mgmt und Mandate Management, generisch
|
|
|
|
Im Frontend soll im generischen Formular "generic-entity.js" für ein neues Objekt die ID entweder hidden oder schreibgeschützt sein. die ID wird nicht benötigt, sondern wird erst mit dem speichern in der datenbank erstellt. d.h. nach dem speichern in der datenbank werden die daten der entsprechenden tabelle neu geladen.
|
|
|
|
|
|
Kannst du mir bitte code struktur und logik das 'agentservice_interface.py' anpsssen und die code struktur zur besseren wartung und weiterenwticklung verbessern:
|
|
|
|
1. die anbindung der ai-modelle mit den entsprechenden config-daten und den funktionsaufrufen in separate dateien auslagern ("connector_ai_openai","connector_ai_webscraping"). im 'agentservice_interface.py' die connector module bei der initialisierung importieren und vorbereiten.
|
|
|
|
2. den agenten-chat 'execute_workflow' nicht in der reihenfolge der agents ausführen, sondern als tischrunde der agents.das heisst ein AI moderator moderiert die agenten autonom und ruft anhand der produzierten antworten und der eigenschaften der agentss den jeweils nächsten geeigneten agenten anhand der 'capabilities' auf, nachdem ein agent seine antwort geliefert hat.
|
|
der initiale prompt mit den zugehörigen files und dem chatverlauf im 'LogEntry' mit den n letzten Datensätzen (n wird aus dem Config file aus der variablen Application.MAX_HISTORY gelesen) wird in ein 'message'-objekt als dictionary transformiert, welches so aussieht:
|
|
message = {
|
|
"role": "user", #--> statisch, immer so
|
|
"content": [ #--> liste der Files
|
|
{
|
|
"type": "text",
|
|
"text": prompt_text
|
|
},
|
|
{
|
|
"type": content_type, # --> diese funktion integrieren wir später
|
|
"source": {
|
|
"type": "base64",
|
|
"media_type": mime_type,
|
|
"data": base64_file # --> hier das dateiname der jeweiligen datei
|
|
}
|
|
},
|
|
{
|
|
"type": "text",
|
|
"text": LogEntries # --> hier die LogEinträge als Textpaket
|
|
}
|
|
]
|
|
}
|
|
wenn der AI moderator der Meinung ist, dass die aufgabe erfüllt ist, beendet er den workflow.
|
|
|
|
|
|
3. initialisierungsset: beantwortet Anfragen direkt mit dem hinterlegten KI Modell, welche keine spezialisierten Agenten benötigen. Dies ist die Generierung von Text, Code, Strukturen, die Analyse von Files, Graphiken erstellen, etc.
|
|
(Agent) Organisator: Dieser analysiert den User Prompt und strukturiert die auszuführenden Aufräge sowie die nötigen zu liefernden Resultate
|
|
(Agent) Entwickler: Dieser entwickelt python code im Auftrag der anderen Agents und führt ihn anschliessend aus
|
|
(Agent) Webscrape: Ein Agent, welcher webscraping durchführt. Dieser nutzt die Funktion '_scrape_url', um eine Webseite zu scannen und den Inhalt zurückzugeben. Er kann auch den Entwickler beauftragen, einen Code zu generieren, welcher die funktion _scrape_url mit einer logik (z.B. iterativ oder batch-mässig) ausführt
|
|
(Prompt): Kannst Du mir ein paar initiale Prompts für die folgenden Fragebereiche vorbereiten, welche ausgewählt werden können:
|
|
. Web Research
|
|
. Analyse
|
|
. Protokoll
|
|
. Design
|
|
|
|
|
|
4. Kannst Du bitte die fehlenden CRUD Methoden in den modulen "workspaces" und "prompts" ergänzen. Ich glaube, es fehlen Post und Delete.
|
|
|
|
|
|
5. Datenbank-Management verbessern: In den zwei Modulen "gateway_interface.py" und "lucydom_interface" finden keine Manipulationen oder Referenzierungen mit ID's statt. Die ID's für einen neuen Datensatz werden nur in "connector_....py" modulen vergeben. Jeder datensatz hat eine unique id. in den modulen "...interface.py" werden keine id's generiert. die abfrage für die id=1 wird ersetzt mit der funktion 'get_initial_id', welche weiter unten erklärt ist.
|
|
Dazu bitte die Module anpassen und in den Modulen "connector...py" eine system-tabelle ergänzen, welche sich merkt, welche ID der erste datensatz jeder tabelle hat, denn dieser ist der jeweilige system-datensatz. dann eine funktion 'get_initial_id' erfassen, welche in den modulen Modulen "gateway_interface.py" und "lucydom_interface" aufgerufen werden kann, um die id des initialen datensatzes pro tabelle abzufragen.
|
|
|
|
|
|
|
|
|
|
|
|
der gateway funktioniert noch nicht ganz.
|
|
kannst mir bitte die module prüfen und besser stukturieren?
|
|
|
|
Diese anforderungen und das setting der dateien:
|
|
|
|
models.py: die datei umbenennen in "model_lucydom.py"
|
|
- die class "User", "UserInDB", "Token" in der datei entfernen und in eine separate datei "model_gateway.py" auslagern.
|
|
- alle datentypen-definitionen sind hier, abschliessend und unabhängig vom datenbanksystem.
|
|
- alle ID's sind long-Zahlen, keine Texte
|
|
- bei jeder class und bei jedem attribut einer class ein label ergänzen, was der name des attributes bzw. der class ist, wenn dies in einem formular abgefragt wird. das label soll einen defaultwert haben und pro sprache gesetzt werden können.
|
|
- alle objekte mandantenfähig machen, d.h. bei jedem Objekt die Attribute "mandate_id" und "user_id" ergänzen.
|
|
|
|
model_gateway.py:
|
|
- alle datentypen-definitionen sind hier, abschliessend und unabhängig vom datenbanksystem.
|
|
- alle ID's sind long-Zahlen, keine Texte
|
|
- bei jeder class und bei jedem attribut einer class ein label ergänzen, was der name des attributes bzw. der class ist, wenn dies in einem formular abgefragt wird. das label soll einen defaultwert haben und pro sprache gesetzt werden können.
|
|
- Die class "Mandate" mit den Attributen (id,name,language) ergänzen
|
|
- Bei der class "User" die "id" und "mandate_id" und "language" ergänzen
|
|
- alle objekte mandantenfähig machen, d.h. bei jedem Objekt die Attribute "mandate_id" und "user_id" ergänzen.
|
|
|
|
database.py aufteilen in 2 files "connector_db_json.py" und "interface_lucydom.py".
|
|
|
|
connector_db_json.py: Ein erster Konnektor von zukünftig weiteren Konnektoren
|
|
1. Parameter, welche übergeben werden:
|
|
- DB_Folder, DB_USER und DB_APIKEY
|
|
- Kontextparamter für "mandate_id" und "user_id", welche nicht null sein dürfen.
|
|
- Die aktuelle JSON-Datenbank im Folder DB_Folder einbinden und so übernehmen, wie sie ist. Falls der Folder fehlt, diesen erstellen.
|
|
2. Der Konnector "db" wird als Objekt zur verfügung gestellt.
|
|
3. Es werden diese generischen Methoden im Objekt "db" zur Verfügung gestellt. jede abfrage filtert automatisch die datensätze auf die Kontextparamter "mandate_id" und "user_id", sofern diese Parameter in einem Datensatz nicht null oder "" sind.
|
|
- get_tables(optional filterkriterien): liste aller tabellen
|
|
- get_fields(table, optional filterkriterien): liste aller attribute einer tabelle
|
|
- get_schema(table, language, optional filterkriterien): objekt aller attribute einer tabelle mit ihrem Datentyp und dem Label in der entsprechenden Sprache. Ohne Sprache Angabe wird der Default Wert als Label genommen
|
|
- get_recordset(table, optional filterkriterien für fields, optional filterkriterien für records): liefert das entsprechende datenobjekt mit den Datensätzen
|
|
- record_create(table,json with attributes): ergänzt einen Datensatz im Kontext "mandate_id", alle attribute, welche nicht im "json with attributes" drin sind, werden auf die standardwerte gemäss dem models.py gesetzt
|
|
- record_delete: löscht einen Datensatz, aber nur wenn es im Kontext "mandate_id" ist, sonst Verweigerung "Not your mandate"
|
|
- record_modify: ändert einen Datensatz, aber nur wenn er im Kontext "mandate_id" ist, sonst Verweigerung "Not your mandate"
|
|
|
|
interface_lucydom.py: Ein Interface zum Gateway, es werden weitere Interfaces folgen. Das Interface macht dies:
|
|
1. Die Datenbank mit diesen Parametern einbinden:
|
|
- Connector "connector_db_json.py"
|
|
- Datenbank "/data_lucydom"
|
|
- Datenmodell "model_lucydom.py"
|
|
2. Das Objekt "db" kann nun genutzt werden
|
|
3. initialisierung der Datenbank, falls sie nicht existiert, aber nur die minimal nötigen Objekte: Der "Default Workspace" in "workspaces"
|
|
|
|
interface_gateway.py: Ein Interface zum Gateway, es werden weitere Interfaces folgen. Das Interface macht dies:
|
|
1. Die Datenbank mit diesen Parametern einbinden:
|
|
- Connector "connector_db_json.py"
|
|
- Datenbank "/data_gateway"
|
|
- Datenmodell "model_gateway.py"
|
|
2. Das Objekt "db" kann nun genutzt werden
|
|
3. initialisierung der Datenbank, falls sie nicht existiert, aber nur die minimal nötigen Objekte: User "Admin", Mandate "Root"
|
|
|
|
app.py: Die Initialisierung klar strukturieren und die Endpunkte gemäss der neuen Struktur anpassen
|
|
1. Teil: Interfaces einbinden.
|
|
2. Alle nötigen Initialisierungen: diese sollen in den jeweiligen Interfaces drin sein, ausser die generischen Teile.
|
|
3. Alle Access & Security Funktionen auslagern in "auth.py"
|
|
4. Alle Token-Endpunkte komplett generisch halten und vereinfachen:
|
|
- Dort keine Attributdefinitionen oder Feld-Listen reinnehmen. Wenn ein Modell angepasst wird, sollen hier keine Anpassungen nötig sein.
|
|
- Die Abfragen und exceptions mit Hilfsfunktionen vereinfachen, sodass die Modellierung der Endpunkte für den Programmierer sehr einfach, übersichtlich und klar ist.
|
|
- Tasks als Kommentare erfassen, was mit all diesen Aenderungen der Endpunkte im Frontend umgebaut werden muss.
|
|
|
|
|
|
agent_service.py: Umbenennen in "interface_agentservice.py"
|
|
- Bei allen Workflow-Endpunkten, welche nur von einem Interface Logik beziehen, die Logik im Interface integrieren und den Code beim Endpunkt vereinfachen.
|
|
- Nur bei Endpunkten, welche Logik kombiniert von mehreren Interfaces benötigen, die Logik beim Endpunkt integrieren
|
|
- Ziel soll es sein, dass die Endpunkte-Codestruktur maximal schlank und übersichtlich ist, also auch die Strukturierung und Gruppierung der Endpunkte
|
|
|
|
|