Trading Tool

Webbasiertes Go/MariaDB-System für Trading-Anfragen, dynamische Workflows und abteilungsbezogene Quests.

Enthalten

• Go Webserver mit net/http und html/template
• Pocket ID / OIDC Login
• MariaDB Datenbank
• automatische Migrationen
• Admin-Konfiguration
• Trading-Anfragen für Ankauf und Verkauf
• Workflow-Regeln mit condition_json und actions_json
• Quest-Templates
• Quest-Abhängigkeiten: nur die erste Quest ist offen, Folgequests warten
• automatische Freischaltung der nächsten Quest nach Abschluss der vorherigen Quest
• automatische Request-Statusberechnung
• Abteilungsportale unter /departments
• Auftragnehmer-Rückmeldungen, Blocker, Änderungswünsche und Abschlussmeldungen
• Dockerfile und Docker Compose

Start

cp .env.example .env
# Pocket ID Werte in .env eintragen
docker compose up --build

App: http://localhost:8080

Pocket ID Callback URL:

http://localhost:8080/auth/callback

Wichtige Routen

• / Trading Dashboard
• /requests/new neue Anfrage
• /departments Abteilungsportale
• /departments/{id}/quests Quest-Ansicht einer Abteilung
• /admin Konfiguration

Workflow Conditions

condition_json entscheidet, wann eine Workflow-Regel greift. Beispiele:

{
  "kind": "buy",
  "item_category": "weapon",
  "quantity_min": 1,
  "price_min": 1000
}

Unterstützte Felder:

• kind
• item_category
• quantity_min
• quantity_max
• price_min
• price_max

actions_json enthält die Quest-Template-Typen in Reihenfolge:

["logistics_quote", "mining_procure", "crafting_order", "delivery"]

Die Reihenfolge erzeugt automatisch Abhängigkeiten. Quest 2 wartet auf Quest 1, Quest 3 wartet auf Quest 2 usw.

Statuslogik

Requests:

• new
• in_progress
• blocked
• fulfilled
• cancelled

Quests:

• waiting
• open
• accepted
• in_progress
• blocked
• change_requested
• done
• cancelled

Wenn alle Quests eines Requests done sind, wird der Request automatisch auf fulfilled gesetzt. Wenn eine Quest blocked ist, wird der Request auf blocked gesetzt. Wenn eine Quest abgeschlossen wird, werden wartende Folgequests automatisch geöffnet, sobald alle Abhängigkeiten erledigt sind.

Hinweise zur Produktionsnutzung

Dieses Paket ist deutlich robuster als der erste Prototyp, ersetzt aber keine finale Sicherheits- und Lastprüfung für deine konkrete Umgebung. Vor echter Produktion solltest du mindestens erledigen:

• HTTPS und sichere Reverse-Proxy-Konfiguration
• langes zufälliges SESSION_SECRET
• restriktive admin_emails
• Backups für MariaDB
• Monitoring/Logging
• eventuell CSRF-Schutz für schreibende Formulare
• rollenbasierte Einschränkung pro Abteilung, falls nicht jeder eingeloggte Nutzer jede Abteilung sehen darf

Fehlerbehebung: [mysql] invalid connection

Diese Version setzt die MariaDB-Verbindungen bewusst kurzlebiger und führt Migrationen ohne multiStatements=true aus. Das verhindert, dass die App alte oder von MariaDB geschlossene TCP-Verbindungen aus dem Pool wiederverwendet.

Nach dem Update bitte neu bauen:

docker compose down
docker compose up --build

Falls du vorher mit einer leeren Testdatenbank gearbeitet hast und komplett neu starten möchtest:

docker compose down -v
docker compose up --build