omsorgCore/CLAUDE.md documents vendor/ as committed so the app can run
without a composer install step, but the generator's own .gitignore
(api-client-php/.gitignore) excludes /vendor/ - it only ever existed
untracked on disk locally, which is why the Docker build worked for me
but mitarbeiter-app crashed at runtime on a real (fresh-checkout) deploy:
"Failed opening required '.../api-client-php/vendor/autoload.php'".
Verified by building from a git-archive-simulated fresh checkout with
this fix applied - mitarbeiter-app's login page now renders without the
fatal error.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Rebuilding and pushing all three images on every commit was unnecessary
churn - the workflow now triggers exclusively on v* tags, so :latest
tracks the last released version instead of the last commit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The root .htaccess forces HTTPS via `RewriteCond %{HTTPS} !=on`. Behind a
reverse proxy that terminates TLS and forwards to Apache over plain HTTP,
%{HTTPS} is always "off" - verified via mod_rewrite trace logging that
this is NOT spoofable via SetEnvIf or a RewriteRule E-flag, despite that
being commonly recommended; %{HTTPS} reflects only the actual TLS
connection to Apache. Every request was therefore redirected to https://,
which the proxy forwarded back over HTTP, looping forever (browser: "the
page isn't redirecting properly").
Fix: .htaccess's redirect condition also accepts a trusted
X-Forwarded-Proto: https header as evidence the request is already
HTTPS. omsorgWeb/docker/000-default.conf additionally sets HTTPS=on in
the request environment when that header is present, so mod_headers'
`env=HTTPS` condition (HSTS header) still fires correctly - this part
doesn't affect mod_rewrite's %{HTTPS} but is unrelated to the redirect fix.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- 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>
- docker-compose.yml: pull omsorgcore/omsorgapp/omsorgweb from the Gitea
registry (pinnable via OMSORG_IMAGE_TAG) instead of building locally;
remove the MySQL service (mitarbeiter-app-legacy is unmaintained legacy
code) and switch all persistent storage from named Docker volumes to
bind mounts under /root/data/.
- omsorgWeb/Dockerfile: create the upload/download/etc. directories before
chown'ing them - they're excluded by .gitignore, so a fresh CI checkout
doesn't have them and the build failed there (only worked locally because
of leftover local test files).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- omsorgapp: drop Electron, run as a plain Vite/React browser app; refresh
token moves to an HttpOnly cookie (omsorgCore), CORS added for the new
browser origin, document download/preview switched to Blob-based browser
APIs.
- Add Dockerfiles for omsorgCore, omsorgapp, and omsorgWeb, a docker-compose.yml
wiring Postgres/MySQL/all three apps together, and a Gitea Actions workflow
that builds and pushes images to the repo's container registry on push to
main and on version tags.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Extends omsorgCore with full CRUD for Facility/Contract/Order plus
configurable value lists and an audit trail, and wires the omsorgapp
frontend up to the new facilities, settings, and audit-log modules;
includes a sidebar active-nav-item highlight.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New omsorgWeb/mitarbeiter-app/ replaces the legacy PHP app for now
with just the login flow, built fresh instead of incrementally
refactored. Reuses the already-working omsorgCore JWT auth pattern
(login, silent refresh, session-stored token pair, /api/auth/me for
role+permissions) but drops everything legacy carried alongside it:
no local MySQL user cache, no admin/user-management endpoints, no
admin UI. Employee/user management stays exclusive to OMSORG Desktop
per architecture decision - Connect only ever acts on the current
user's own session.
logout.php additionally revokes the refresh token server-side via
omsorgcore_logout(), which the legacy version never did.
Verified end-to-end against a running omsorgCore instance: login,
dashboard via /api/auth/me, logout + token revocation, unauth
redirect, and wrong-credential error handling.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Consolidates the previously separate omsorgapp and omsorgCore repos
(each had their own nested .git with GitHub history) plus the old
root-level website/mitarbeiter-app into a single monorepo, matching
the structure already documented in the root CLAUDE.md. Also moves
the PHP employee app aside as omsorgWeb/mitarbeiter-app-legacy/ to
serve as a template for a ground-up rewrite.
Fixes .gitignore in the same pass: the config-secrets/uploads/data
patterns were unanchored (relative to repo root, not depth-agnostic),
so they silently stopped matching once the app moved under omsorgWeb/.
Patterns are now **/-prefixed and cover both mitarbeiter-app and
mitarbeiter-app-legacy, keeping DB/SMTP credentials and uploaded
employee documents out of version control.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
