jbergner
02e7b7f4c5
All checks were successful
release-tag / release-image (push) Successful in 2m30s
130 lines
3.3 KiB
Markdown
130 lines
3.3 KiB
Markdown
# 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
|
|
|
|
```bash
|
|
cp .env.example .env
|
|
# Pocket ID Werte in .env eintragen
|
|
docker compose up --build
|
|
```
|
|
|
|
App: http://localhost:8080
|
|
|
|
Pocket ID Callback URL:
|
|
|
|
```text
|
|
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:
|
|
|
|
```json
|
|
{
|
|
"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:
|
|
|
|
```json
|
|
["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:
|
|
|
|
```bash
|
|
docker compose down
|
|
docker compose up --build
|
|
```
|
|
|
|
Falls du vorher mit einer leeren Testdatenbank gearbeitet hast und komplett neu starten möchtest:
|
|
|
|
```bash
|
|
docker compose down -v
|
|
docker compose up --build
|
|
```
|