5293810529
Zwei Fehler in der EAN-Liste einer Gruppe, beide gemeldet und nachgestellt. Derselbe Code stand zweimal in der Liste: einmal schreibgeschuetzt mit der Kennzeichnung "Artikel", einmal darunter mit Notizfeld. Grund war, dass _group_to_out die Codes der Artikel unabhaengig von den Gruppen-Codes zusammengestellt hat - seit die Zuordnung automatisch einen Gruppen-Code anlegt, trifft beides auf denselben Code zu. Die schreibgeschuetzte Zeile stand oben, deshalb war das Notizfeld darunter leicht zu uebersehen. Jetzt gibt es eine Zeile je Code. Der Gruppen-Code fuehrt den Artikel mit, ueber den er dazugehoert (neues Feld product_name in BarcodeOut), zeigt weiterhin die Kennzeichnung "Artikel" - und hat trotzdem ein Notizfeld. Der Muelleimer entfaellt bei diesen Codes, denn sie kaemen beim naechsten Speichern des Artikels sofort zurueck; dafuer muss der Artikel die Gruppe wechseln. Zweitens fehlte fuer bestehende Daten der Code ganz. Die automatische Pflege greift nur beim Anlegen und Aendern eines Artikels; Zuordnungen, die es vorher schon gab, hatten nie einen Gruppen-Code bekommen. In der Verwaltung stand der Code deshalb ausschliesslich als schreibgeschuetzte Artikel-Zeile - genau die Stelle, an der sich keine Notiz hinterlegen liess. Neu holt backfill() das beim Start nach: fuer jeden Artikel mit Gruppe und Barcode wird der Gruppen-Code angelegt, sofern er fehlt. Gefahrlos wiederholbar. Getestet: 58 pytest-Tests gruen, einer neu (Backfill legt den fehlenden Code an und beim zweiten Lauf nichts doppelt). Der gemeldete Fall wurde vorher gegen die laufende API nachgestellt - Altbestand ohne Gruppen-Code und ein doppelt gelisteter Code nach einer Neuanlage - und danach als behoben bestaetigt: eine Zeile je Code, mit Artikelnamen und Notizfeld. Web-Build laeuft durch. Die Oberflaeche habe ich nicht selbst bedient. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
🥫 Project-Good – Selfhostbare Lebensmittel-Lagerverwaltung
Ein selbst gehosteter Dienst zur Verwaltung deines Lebensmittelvorrats: Ein-/Auslagern per Barcode, MHD-/Ablaufverwaltung mit Chargen, Mindestbestände, automatische Einkaufsliste – mit Web-UI und (in Vorbereitung) nativer iOS-App.
Dies ist Schritt 1 (Fundament). Der komplette Fahrplan steht in docs/ROADMAP.md.
Features (Schritt 1)
- Barcode-Lookup über Open Food Facts mit lokalem Fallback (unbekannte Produkte selbst anlegen).
- Chargen mit MHD: Jedes Einlagern erzeugt eine Charge mit eigenem Mindesthaltbarkeitsdatum. Beim Auslagern wird automatisch die zuerst ablaufende Charge zuerst entnommen (FEFO – First Expired, First Out).
- Einheiten: Basiseinheit Stück / Gramm / Milliliter plus optionale Packungsgröße → Ein-/Auslagern in Packungen oder Teilmengen (z. B. 200 g).
- Mindestbestände pro Produkt → automatische Einkaufsliste.
- Ablaufwarnung für bald ablaufende Chargen (Frist konfigurierbar).
- Lagerorte (flach; Unterlagerorte folgen in Schritt 3).
- Mehrbenutzer mit Rollen:
- Admin – verwaltet Produkte, Lagerorte, Benutzer, Mindestbestände.
- Nutzer – nur ein-/auslagern und ansehen.
- Bewegungen werden protokolliert (wer hat wann was ein-/ausgelagert).
Architektur
| Teil | Technik |
|---|---|
| Backend | Python · FastAPI · SQLAlchemy |
| DB | PostgreSQL |
| Web-UI | React · Vite (via nginx ausgeliefert) |
| iOS | SwiftUI (Schritt 2) |
| Deploy | Docker Compose · install.sh |
backend/ FastAPI-App + Tests
web/ React/Vite SPA
deploy/ docker-compose.yml, install.sh, .env.example
docs/ Roadmap
Installation (selfhosted, Linux)
Voraussetzung: eine Linux-Maschine (Server, NAS, Raspberry Pi …). Docker wird bei Bedarf automatisch installiert.
git clone https://git.scarriffle.com/Scarriffle/project-good.git
cd project-good/deploy
chmod +x install.sh
./install.sh # interaktiv – fragt Port & Admin-Passwort
# oder vollautomatisch mit generiertem Admin-Passwort:
# ./install.sh --yes
Ist das Gitea-Repo privat, fragt
git clonenach Benutzername + Access-Token. Fallsgitfehlt:apt update && apt install -y git.
Nach dem Start:
- Web-UI:
http://<server-ip>:8080(Port konfigurierbar) - Anmeldung mit dem im Installer angezeigten Admin-Benutzer/Passwort.
Aktualisieren
cd project-good/deploy
./update.sh # holt den neuesten Stand aus Git und baut neu
./update.sh --prune # zusätzlich alte Images aufräumen
./update.sh --no-pull # nur neu bauen, ohne git pull
Das Skript ist von überall aufrufbar, nutzt die vorhandene deploy/.env und
prüft am Ende, ob das Backend wieder erreichbar ist.
Verwaltung:
cd deploy
docker compose logs -f # Logs ansehen
docker compose down # stoppen
docker compose up -d # starten
Die Konfiguration liegt in deploy/.env (Passwörter, Port, JWT-Secret). Für den
Produktivbetrieb bitte hinter einen HTTPS-Reverse-Proxy (z. B. Caddy/Traefik) stellen.
Entwicklung (ohne Docker)
Backend:
cd backend
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
# lokale SQLite-DB nutzen:
export DATABASE_URL="sqlite:///./project_good.db"
uvicorn app.main:app --reload
API-Doku dann unter http://localhost:8000/docs.
Web:
cd web
npm install
npm run dev # http://localhost:5173, proxyt /api → localhost:8000
Tests:
cd backend
pip install -r requirements.txt
pytest # prüft FEFO-Abbuchung und Einheiten-Umrechnung
Nächste Schritte
Native iOS-App (Schritt 2) und fortgeschrittene Features (Gruppen-Intelligenz, Unterlagerorte, Push-Benachrichtigungen …) – siehe docs/ROADMAP.md.