Felix KemmlerandClaude Sonnet 5
dcc8ea1510
Docker-Images bauen und veröffentlichen / build (, omsorgCore/Dockerfile, omsorgcore) (push) Successful in 3s
Docker-Images bauen und veröffentlichen / build (, omsorgWeb/Dockerfile, omsorgweb) (push) Successful in 3s
Docker-Images bauen und veröffentlichen / build (, omsorgapp/Dockerfile, omsorgapp) (push) Successful in 3s
- omsorgapp now reads the omsorgCore URL from a runtime env-config.js generated by the container entrypoint from OMSORG_CORE_URL, instead of only baking it in at image build time - docker-compose.yml pulls pre-built images from the registry, so a build-time-only value couldn't be changed without a rebuild. - docker-compose.yml: omsorgCore gets its own subdomain (core.omsorg-pflegedienste.de) rather than being proxied under the frontend's domain - omsorgWeb never needs browser-side access to it anyway (server-side cURL only), and a dedicated API host is more future-proof without being any less secure (backend still only bound to 127.0.0.1). Includes the nginx server-block snippet needed for the new subdomain. - Drop the now-unused OMSORG_CORE_PUBLIC_URL build-arg wiring from the Gitea Actions workflow. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Omsorg Business Controls Pro – Release 0.1.1 Foundation
Stabile lokale Electron/React-Basis ohne native SQLite-Abhängigkeit.
Warum 0.1.1?
Release 0.1.0 nutzte better-sqlite3. Auf macOS/Electron kann dieses native Modul Versionsprobleme verursachen.
Release 0.1.1 speichert Daten zuerst in einer lokalen JSON-Datenbank im Benutzerordner.
Start
cd ~/Desktop/omsorg-business-controls-pro-release-0.1.1
npm install
npm run dev
Lokale Daten
Die App legt Ordner unter ~/Documents/Omsorg Business Controls Pro an:
- database/omsorg-local-db.json
- documents/employees
- documents/customers
- backups
Nächster Sprint
SQLite wird später sauber über eine entkoppelte Persistenzschicht eingebaut.