Started by GitHub push by younex1Started by an SCM changeStarted by an SCM change33365492e0eebdab580a2e8c2b0c0eea00e89d6063365492e0eebdab580a2e8c2b0c0eea00e89d606refs/remotes/origin/main3365492e0eebdab580a2e8c2b0c0eea00e89d6063365492e0eebdab580a2e8c2b0c0eea00e89d606refs/remotes/origin/main3365492e0eebdab580a2e8c2b0c0eea00e89d6063365492e0eebdab580a2e8c2b0c0eea00e89d606refs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#3 33654923235028038blut24-landing #3 33654923false35444SUCCESS1785220314292https://jenkins.younex.de/job/blut24-landing/3/- .env.exampleserver/utils/registrationValidation.tsserver/api/registration/submit.post.tsd91c3a46ec2b1420a63ba8ecab63a9cb215936161785219798000https://jenkins.younex.de/user/infoinfoinfo@logyou.deregistration: operator test domains may register for any clinic
Adds REGISTRATION_TEST_DOMAINS (comma-separated). Addresses on those domains skip
the "e-mail domain belongs to the chosen Standort" check, so the flow can be
exercised end-to-end against arbitrary clinics.
That check is the only thing preventing a stranger from registering someone else's
hospital, so it is never relaxed for real users. The bypass therefore:
- does not exist at all when the variable is empty or unset (the default)
- never counts as domain-verified (domain_verified stays 0)
- forces needs_manual_approval and prefixes the note with [TESTREGISTRIERUNG via <domain>]
- leaves the freemail blocklist and the per-Standort duplicate guard intact
Verified: younex.de/it-beratung.it accepted for a non-matching Charité Standort;
a non-whitelisted business domain and a freemail address both still rejected; and
with the variable unset younex.de is rejected again.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-28 08:23:18 +0200d91c3a46ec2b1420a63ba8ecab63a9cb21593616registration: operator test domains may register for any cliniceditserver/utils/registrationValidation.tseditserver/api/registration/submit.post.tsedit.env.example
- Jenkinsfiledeploy/deploy.sh3365492e0eebdab580a2e8c2b0c0eea00e89d6061785220306000https://jenkins.younex.de/user/infoinfoinfo@logyou.deci: move the deploy concurrency guard from Jenkins to the target
Every build after the first sat in the queue as a BlockedItem and never started
until Jenkins was restarted - observed three times on this controller. The only
plausible cause was disableConcurrentBuilds(), so it is removed.
The race it guarded against is two deploys swapping the `current` symlink at the
same time. That resource lives on the TARGET, not on Jenkins, so deploy.sh now
takes an flock on /var/lock/blut24-landing-deploy.lock for the whole run. That is
strictly better: it also covers deploys started by hand or from another controller,
which the Jenkins-side option never did.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-28 08:31:46 +02003365492e0eebdab580a2e8c2b0c0eea00e89d606ci: move the deploy concurrency guard from Jenkins to the targeteditJenkinsfileeditdeploy/deploy.sh
githttps://jenkins.younex.de/user/infoinfofalse4https://jenkins.younex.de/job/blut24-landing/4/2https://jenkins.younex.de/job/blut24-landing/2/