https://jenkins.younex.de/job/blut24-landing/blut24-landing — push to main deploys to 192.168.12.81:/var/www/blut24.com/web (zero downtime). Pipeline is defined by the Jenkinsfile in the repo.blut24-landingblut24-landingblut24-landingblut24-landinghttps://jenkins.younex.de/job/blut24-landing/trueStarted by GitHub push by younex11549f3d63e2f1169fda0b321572605cb5f9b6fcd5e49f3d63e2f1169fda0b321572605cb5f9b6fcd5erefs/remotes/origin/main49f3d63e2f1169fda0b321572605cb5f9b6fcd5e49f3d63e2f1169fda0b321572605cb5f9b6fcd5erefs/remotes/origin/main49f3d63e2f1169fda0b321572605cb5f9b6fcd5e49f3d63e2f1169fda0b321572605cb5f9b6fcd5erefs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#15 49f3d633060428038blut24-landing #15 49f3d6315false155476SUCCESS1785257388243https://jenkins.younex.de/job/blut24-landing/15/- app/locales/de.tsscripts/test-registration.mjsserver/api/registration/confirm.post.tsserver/utils/i18n.tsapp/locales/en.tsREADME.md49f3d63e2f1169fda0b321572605cb5f9b6fcd5e1785257378000https://jenkins.younex.de/user/infoinfoinfo@younex.deregistration: keep the manual-review promise — gate ERP onboarding on needs_manual_approval
HANDOFF §4 (ERP repo, reference/blut24/HANDOFF.md). needs_manual_approval gated
nothing: couriers and no-domain clinics — exactly the registrations nothing
could verify — were auto-onboarded into iDempiere with live credentials mailed,
while form, confirmation mail and welcome mail promised a manual review.
confirm.post.ts now skips onboarding for them and records erp_status
'manual-approval'; the operator provisions them by hand. Verified and test
registrations stay fully automatic.
Copy made truthful: the test-domain notice no longer claims "marked for manual
approval" (test domains auto-activate; they are marked internally as test
registrations), and the manual-review texts are courier-neutral instead of
explaining a clinic-only domain lookup.
alreadyConfirmed now returns credentialsSent, read from the stored ERP payload
(setErpResult persists it).
README: the ERP auth section described a Bearer scheme the code never uses —
the token travels as the logship_it cookie, and the ERP's send-credentials
route is now gated on exact equality with the instance's IDEMPIERETOKEN, so
ERP_SERVICE_TOKEN must be exactly that value.
test-registration.mjs: courier confirm asserts needsManualApproval,
credentialsSent=false and erp_status 'manual-approval' (83/83 green).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-28 18:49:38 +020049f3d63e2f1169fda0b321572605cb5f9b6fcd5eregistration: keep the manual-review promise — gate ERP onboarding on needs_manual_approvaleditscripts/test-registration.mjseditapp/locales/en.tseditREADME.mdeditapp/locales/de.tseditserver/api/registration/confirm.post.tseditserver/utils/i18n.ts
githttps://jenkins.younex.de/user/infoinfofalse14https://jenkins.younex.de/job/blut24-landing/14/Started by GitHub push by younex11449c9f2a18725f35f7caed718f3cd9669ca7b504849c9f2a18725f35f7caed718f3cd9669ca7b5048refs/remotes/origin/main49c9f2a18725f35f7caed718f3cd9669ca7b504849c9f2a18725f35f7caed718f3cd9669ca7b5048refs/remotes/origin/main49c9f2a18725f35f7caed718f3cd9669ca7b504849c9f2a18725f35f7caed718f3cd9669ca7b5048refs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#14 49c9f2a2728228038blut24-landing #14 49c9f2a14false145471SUCCESS1785247787466https://jenkins.younex.de/job/blut24-landing/14/- .env.exampleserver/utils/mail.tsapp/components/SectionHero.vueserver/api/registration/submit.post.tsserver/api/registration/confirm.post.tsapp/components/SectionRegistration.vueREADME.mdapp/locales/en.tsserver/utils/registrationTypes.tsapp/locales/de.tsscripts/test-registration.mjsserver/utils/registrationValidation.tsapp/composables/useRegistrationDialog.tsserver/utils/registrationDb.tsserver/utils/erpOnboarding.tsapp/components/RegistrationForm.vueserver/utils/i18n.ts49c9f2a18725f35f7caed718f3cd9669ca7b50481785247772000https://jenkins.younex.de/user/infoinfoinfo@younex.deFixes
2026-07-28 16:09:32 +020049c9f2a18725f35f7caed718f3cd9669ca7b5048Fixeseditserver/api/registration/confirm.post.tseditserver/utils/erpOnboarding.tseditapp/components/RegistrationForm.vueeditapp/locales/de.tsedit.env.exampleeditapp/components/SectionHero.vueeditREADME.mdaddserver/utils/registrationTypes.tseditserver/utils/registrationDb.tseditscripts/test-registration.mjseditserver/api/registration/submit.post.tseditapp/composables/useRegistrationDialog.tseditapp/locales/en.tseditserver/utils/i18n.tseditserver/utils/registrationValidation.tseditserver/utils/mail.tseditapp/components/SectionRegistration.vue
githttps://jenkins.younex.de/user/infoinfofalse15https://jenkins.younex.de/job/blut24-landing/15/13https://jenkins.younex.de/job/blut24-landing/13/Started by GitHub push by younex113595e2c473bdb201384ea147d00098a5c8786b811595e2c473bdb201384ea147d00098a5c8786b811refs/remotes/origin/main595e2c473bdb201384ea147d00098a5c8786b811595e2c473bdb201384ea147d00098a5c8786b811refs/remotes/origin/main595e2c473bdb201384ea147d00098a5c8786b811595e2c473bdb201384ea147d00098a5c8786b811refs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#13 595e2c42622728038blut24-landing #13 595e2c413false135469SUCCESS1785239626779https://jenkins.younex.de/job/blut24-landing/13/- app/components/LangFlag.vueapp/components/SectionHero.vueapp/locales/de.tsapp/components/RegistrationDialog.vueapp/components/SiteHeader.vueapp/locales/en.ts595e2c473bdb201384ea147d00098a5c8786b8111785239613000https://jenkins.younex.de/user/infoinfoinfo@younex.deLanguage switch becomes a borderless flag menu; free-of-charge block moves into the dialog
The switch showed both languages permanently inside a bordered group, spending
header width and visual weight on a control almost nobody touches. It is now a
borderless trigger carrying only the CURRENT language — flag, code and a caret —
that opens a small menu with the alternatives and a tick against the active one.
Chrome appears only on hover, focus or open.
Still two real buttons, so the site-wide focus ring and keyboard operation are
unchanged; aria-haspopup/aria-expanded describe the menu and each entry carries
aria-current. The menu closes on outside click, on Escape and after choosing, and
both listeners are attached only while it is open and removed on unmount.
Flags moved into their own LangFlag component: the Union Jack needs a clipPath and
the glyph now renders up to three times on one page, so a shared literal id would
have made every instance clip against the first one's rect. Drawn as SVG rather
than flag emoji, which do not render as flags on Windows at all.
The free-of-charge block moves out of the hero and into the foot of the
registration dialog, after the form — the cost question is what someone asks once
they have seen how much they are being asked for. Its copy moved from hero.* to
dialog.* to match. The dialog's header subtitle said the same thing directly under
a heading that already reads "Kostenlos … registrieren", so it is dropped rather
than repeated twice in one panel.
Hero grid switched from items-center to items-start, so the "Blutkonserven-Plattform"
eyebrow and the top edge of the stock-matrix card now share a top line.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-28 13:53:33 +0200595e2c473bdb201384ea147d00098a5c8786b811Language switch becomes a borderless flag menu; free-of-charge block moves into the dialogaddapp/components/LangFlag.vueeditapp/locales/de.tseditapp/components/SectionHero.vueeditapp/locales/en.tseditapp/components/RegistrationDialog.vueeditapp/components/SiteHeader.vue
githttps://jenkins.younex.de/user/infoinfofalse14https://jenkins.younex.de/job/blut24-landing/14/12https://jenkins.younex.de/job/blut24-landing/12/Started by GitHub push by younex112992a7b175443cc5ffeadaac8c785d913ecc1b57d992a7b175443cc5ffeadaac8c785d913ecc1b57drefs/remotes/origin/main992a7b175443cc5ffeadaac8c785d913ecc1b57d992a7b175443cc5ffeadaac8c785d913ecc1b57drefs/remotes/origin/main992a7b175443cc5ffeadaac8c785d913ecc1b57d992a7b175443cc5ffeadaac8c785d913ecc1b57drefs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#12 992a7b12771028038blut24-landing #12 992a7b112false125466SUCCESS1785238671688https://jenkins.younex.de/job/blut24-landing/12/- app/components/SiteHeader.vueapp/assets/css/main.cssapp/components/SectionHero.vue992a7b175443cc5ffeadaac8c785d913ecc1b57d1785238658000https://jenkins.younex.de/user/infoinfoinfo@younex.deFlag-led language switch; move the free-of-charge message under the stock matrix
The language toggle filled its active half with --color-blood-700 — the same red as
the primary "Registrieren" button — so two red elements sat side by side in the
header and the switch competed with the one action that matters. It is now
flag-led: the flag carries the meaning, selection is shown by saturation plus a
neutral tinted background, and red goes back to belonging to the CTA alone.
The DE/EN code stays beside each flag deliberately. A flag denotes a country
rather than a language, and the Union Jack for "English" is a convention rather
than a fact, so the text is what actually disambiguates; both buttons keep their
aria-label and gain a title.
The free-of-charge block moves out of the hero's left column to sit under the
stock matrix, so the reader meets it right after seeing what the product does
rather than beside the headline. Recoloured red to green: red is the blood and
brand colour and made a reassurance read like an alert. Green is the conventional
"no cost" signal and nothing else on the page uses it, so it stands out without
competing. Added as contrast-checked --color-free-* tokens rather than stock
emerald, matching how the rest of the palette is defined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-28 13:37:38 +0200992a7b175443cc5ffeadaac8c785d913ecc1b57dFlag-led language switch; move the free-of-charge message under the stock matrixeditapp/components/SiteHeader.vueeditapp/components/SectionHero.vueeditapp/assets/css/main.css
githttps://jenkins.younex.de/user/infoinfofalse13https://jenkins.younex.de/job/blut24-landing/13/11https://jenkins.younex.de/job/blut24-landing/11/Started by GitHub push by younex1111b159ec466b3092fcd9e053fc84a89b6f54023fb1b159ec466b3092fcd9e053fc84a89b6f54023fbrefs/remotes/origin/main1b159ec466b3092fcd9e053fc84a89b6f54023fb1b159ec466b3092fcd9e053fc84a89b6f54023fbrefs/remotes/origin/main1b159ec466b3092fcd9e053fc84a89b6f54023fb1b159ec466b3092fcd9e053fc84a89b6f54023fbrefs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#11 1b159ec2573228038blut24-landing #11 1b159ec11false115464SUCCESS1785238001631https://jenkins.younex.de/job/blut24-landing/11/- server/utils/mail.tsapp/components/SectionWaste.vueapp/pages/bestaetigung.vueserver/api/registration/submit.post.tsapp/components/SiteFooter.vueapp/components/SiteHeader.vueserver/api/registration/confirm.post.tsapp/components/SectionRegistration.vueapp/pages/datenschutz.vueapp/locales/en.tsapp/composables/useLocale.tsnuxt.config.tsapp/components/SectionBenefit.vueapp/locales/de.tsserver/utils/registrationValidation.tsapp/components/SectionFeatures.vueapp/composables/useRegistrationDialog.tsapp/locales/detect.tsapp/components/AndroidBadge.vueapp/locales/index.tsapp/components/RegistrationForm.vueserver/utils/i18n.tsapp/components/SectionProof.vueapp/components/StockMatrixPreview.vueapp/components/LegalTranslationNotice.vueapp/pages/index.vueapp/app.vueapp/components/SectionHero.vueREADME.mdapp/components/SectionCourier.vueapp/components/SectionHowItWorks.vueapp/components/SectionApp.vueapp/components/RegistrationDialog.vueapp/pages/impressum.vuescripts/test-registration.mjsserver/utils/registrationDb.ts1b159ec466b3092fcd9e053fc84a89b6f54023fb1785237988000https://jenkins.younex.de/user/infoinfoinfo@younex.deFull DE/EN with runtime switch, benefit-led section, free-of-charge messaging
English translation with a language switch in the header. Uses a typed message
catalogue plus a small composable rather than @nuxtjs/i18n: the site is 12
components and 4 pages, and i18n would add vue-i18n plus a build transform and
want to own the URL space (/en/...), breaking every in-page anchor and every link
already shared. Both languages live on one URL, so a shared link always works.
en.ts is typed against de.ts, so a missing key fails the type check.
Locale precedence is ?lang= then the b24_lang cookie then Accept-Language, with
German winning on absence, ties, wildcards and unparsable input. It is resolved
once on the server and carried through the payload, so hydration cannot disagree.
Confirmation, welcome and duplicate mails follow the language stored on the
registration row rather than the language of whoever triggered them; the internal
ops mail stays German.
Impressum and Datenschutz are translated for comprehension only — the English
pages carry a notice that the German version is solely authoritative and link
back to it. "Freiberufler" is left untranslated with a gloss because the English
options all name different legal statuses, and German statute short names are
kept. The privacy notice now discloses the b24_lang cookie.
"Verfall & Kosten" becomes "Ihr Vorteil" / "Your benefit", led by the gain rather
than the loss. The worked example stays labelled as our own assumption — no
invented statistics. #vorteil is the new anchor and #verfall still resolves.
Free registration and use is stated in the hero, the proof band, the registration
CTA and the dialog header, claiming only what is actually free.
Fixes the dialog keeping the last confirmation screen: reopening after a completed
submission resets the form, while dismissing mid-typing keeps every keystroke,
because the reset runs on open and only when the previous run finished. Replaces
"Weitere Einrichtung registrieren" with a plain close action.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-28 13:26:28 +02001b159ec466b3092fcd9e053fc84a89b6f54023fbFull DE/EN with runtime switch, benefit-led section, free-of-charge messagingeditapp/components/AndroidBadge.vueeditapp/components/SectionHero.vueaddserver/utils/i18n.tseditserver/utils/mail.tsaddapp/locales/en.tseditREADME.mdeditapp/components/RegistrationDialog.vueeditapp/components/RegistrationForm.vueeditapp/components/SectionFeatures.vuedeleteapp/components/SectionWaste.vueeditserver/utils/registrationValidation.tsaddapp/locales/index.tseditserver/api/registration/confirm.post.tseditserver/utils/registrationDb.tsaddapp/locales/detect.tseditapp/components/SectionCourier.vueeditapp/components/SiteFooter.vueeditapp/components/SectionHowItWorks.vueeditapp/pages/index.vueaddapp/components/LegalTranslationNotice.vueeditapp/components/StockMatrixPreview.vueeditapp/composables/useRegistrationDialog.tseditapp/components/SectionApp.vueeditnuxt.config.tsaddapp/locales/de.tseditapp/components/SiteHeader.vueeditapp/pages/bestaetigung.vueeditapp/components/SectionProof.vueeditapp/pages/datenschutz.vueeditapp/pages/impressum.vueeditscripts/test-registration.mjseditserver/api/registration/submit.post.tseditapp/components/SectionRegistration.vueeditapp/app.vueaddapp/components/SectionBenefit.vueaddapp/composables/useLocale.ts
githttps://jenkins.younex.de/user/infoinfofalse12https://jenkins.younex.de/job/blut24-landing/12/10https://jenkins.younex.de/job/blut24-landing/10/Started by GitHub push by younex110a5ea20018abc28385336941df5780f7d1753e72ea5ea20018abc28385336941df5780f7d1753e72erefs/remotes/origin/maina5ea20018abc28385336941df5780f7d1753e72ea5ea20018abc28385336941df5780f7d1753e72erefs/remotes/origin/maina5ea20018abc28385336941df5780f7d1753e72ea5ea20018abc28385336941df5780f7d1753e72erefs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#10 a5ea2002620028038blut24-landing #10 a5ea20010false105461SUCCESS1785232956187https://jenkins.younex.de/job/blut24-landing/10/- scripts/test-registration.mjsa5ea20018abc28385336941df5780f7d1753e72e1785232944000https://jenkins.younex.de/user/infoinfoinfo@logyou.detest: courier freemail is now accepted, not rejected
The suite still asserted the old rule and failed on the previous commit — I
pushed without reading the result. The assertion now matches the intended
behaviour and explains why, so it does not read as a weakened check: couriers are
not tied to a clinic domain and are reviewed manually, while the freemail block
for clinics is asserted separately and unchanged.
38 checks, 0 failures.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-28 12:02:24 +0200a5ea20018abc28385336941df5780f7d1753e72etest: courier freemail is now accepted, not rejectededitscripts/test-registration.mjs
githttps://jenkins.younex.de/user/infoinfofalse11https://jenkins.younex.de/job/blut24-landing/11/9https://jenkins.younex.de/job/blut24-landing/9/Started by GitHub push by younex19f182d455db3a8ce7361ae7d2e691c06efffe267bf182d455db3a8ce7361ae7d2e691c06efffe267brefs/remotes/origin/mainf182d455db3a8ce7361ae7d2e691c06efffe267bf182d455db3a8ce7361ae7d2e691c06efffe267brefs/remotes/origin/mainf182d455db3a8ce7361ae7d2e691c06efffe267bf182d455db3a8ce7361ae7d2e691c06efffe267brefs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#9 f182d452607828038blut24-landing #9 f182d459false95459SUCCESS1785232906182https://jenkins.younex.de/job/blut24-landing/9/- server/utils/mail.tsserver/api/registration/submit.post.tsapp/components/RegistrationForm.vueserver/utils/registrationValidation.tsf182d455db3a8ce7361ae7d2e691c06efffe267b1785232895000https://jenkins.younex.de/user/infoinfoinfo@logyou.deregistration: switching type must not carry the other branch's data
Reported from real use: pick a clinic, switch to "Kurierdienst", register — and
the confirmation mail arrived as "Medizinischer Kurierdienst / Einrichtung:
Facharztklinik Hamburg / Anschrift: Martinistraße 78". There was no watcher on
form.type at all, so stoid/orgName/street/plz/city kept the clinic's values and
the courier branch submits those fields verbatim. Switching type now clears the
clinic selection, the address fields and the related errors.
Couriers may register with any address, freemail included — they are not tied to
a clinic domain and every courier registration is reviewed manually anyway. The
block stays for clinics, where the domain is what proves the registrant belongs
to the Standort they picked. Enforced on the server too, not just in the form.
The confirmation mail is now written per type: a courier is not a clinic, so it
gets its own description (orders on the phone, confirm pickup/delivery in the
app, free, manual review) and the detail row reads "Unternehmen" rather than
"Einrichtung". Both the HTML and the plain-text alternative.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-28 12:01:35 +0200f182d455db3a8ce7361ae7d2e691c06efffe267bregistration: switching type must not carry the other branch's dataeditserver/api/registration/submit.post.tseditserver/utils/mail.tseditapp/components/RegistrationForm.vueeditserver/utils/registrationValidation.ts
githttps://jenkins.younex.de/user/infoinfofalse10https://jenkins.younex.de/job/blut24-landing/10/8https://jenkins.younex.de/job/blut24-landing/8/Started by GitHub push by younex18b1a7c4026f44521453558a428303a0537697bedab1a7c4026f44521453558a428303a0537697bedarefs/remotes/origin/mainb1a7c4026f44521453558a428303a0537697bedab1a7c4026f44521453558a428303a0537697bedarefs/remotes/origin/mainb1a7c4026f44521453558a428303a0537697bedab1a7c4026f44521453558a428303a0537697bedarefs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#8 b1a7c402605728038blut24-landing #8 b1a7c408false85457SUCCESS1785232726165https://jenkins.younex.de/job/blut24-landing/8/- .env.exampleapp/components/RegistrationForm.vuenuxt.config.tsb1a7c4026f44521453558a428303a0537697beda1785232713000https://jenkins.younex.de/user/infoinfoinfo@logyou.deregistration: the FORM also has to know about the test domains
A whitelisted address was still rejected with "Die Domain gehört nicht zu …".
The server accepted it — I had only ever tested the server with curl, which
bypasses the form entirely. The browser does its own domain check for instant
feedback and knew nothing about REGISTRATION_TEST_DOMAINS, so it blocked the
submit before the request was ever sent. Verified the wrong layer, missed the bug.
The list is now mirrored into runtimeConfig.public and consulted by both the
submit guard and the blur handler. Publishing it is acceptable: it is a temporary
operator feature (empty in real production) and a bypassed registration still has
to confirm a mail delivered to that domain, so knowing the name grants nothing.
The blur notice does NOT claim the domain "matches the Standort" — that would be
untrue. It says it is a test domain and that the registration is flagged for
manual approval.
Note the two-name trap, documented in .env.example: REGISTRATION_TEST_DOMAINS is
read server-side, NUXT_PUBLIC_REGISTRATION_TEST_DOMAINS by the browser. Set both
or the form and the server disagree — which is exactly this bug.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-28 11:58:33 +0200b1a7c4026f44521453558a428303a0537697bedaregistration: the FORM also has to know about the test domainseditapp/components/RegistrationForm.vueeditnuxt.config.tsedit.env.example
githttps://jenkins.younex.de/user/infoinfofalse9https://jenkins.younex.de/job/blut24-landing/9/7https://jenkins.younex.de/job/blut24-landing/7/Started by GitHub push by younex174476c9c4298767c7d1e75e392fda5233727c5d914476c9c4298767c7d1e75e392fda5233727c5d91refs/remotes/origin/main4476c9c4298767c7d1e75e392fda5233727c5d914476c9c4298767c7d1e75e392fda5233727c5d91refs/remotes/origin/main4476c9c4298767c7d1e75e392fda5233727c5d914476c9c4298767c7d1e75e392fda5233727c5d91refs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#7 4476c9c2682928038blut24-landing #7 4476c9c7false75453SUCCESS1785228855796https://jenkins.younex.de/job/blut24-landing/7/- app/components/SectionCourier.vueapp/components/SectionHowItWorks.vueapp/components/SectionHero.vueapp/components/SiteFooter.vueapp/components/SectionRegistration.vueapp/components/SectionProof.vue4476c9c4298767c7d1e75e392fda5233727c5d911785228842000https://jenkins.younex.de/user/infoinfoinfo@logyou.delanding: copy pass — courier value proposition, step 4, spacing, footer
- Step 4 now says what actually happens: if the other clinic is on Blut24 too,
order, delivery note and unit data stay inside the system with nothing retyped
or faxed; DGTI-Lieferschein, PDF and e-mail remain available for houses that
are not yet connected, rather than being the default path.
- Courier section rewritten around the app: orders arrive on the phone, pickup
and delivery are confirmed there, and participation is free so a courier can
win additional runs without buying software. Kept strictly to goods transport
wording - no patient-transport terms.
- "dauerhaft kostenlos" -> "für Kliniken kostenlos" everywhere.
- Tightened the gap between the header and the hero headline on both breakpoints.
- Dropped the Bundes-Klinik-Atlas source line from the footer.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-28 10:54:02 +02004476c9c4298767c7d1e75e392fda5233727c5d91landing: copy pass — courier value proposition, step 4, spacing, footereditapp/components/SectionHowItWorks.vueeditapp/components/SectionProof.vueeditapp/components/SectionRegistration.vueeditapp/components/SectionHero.vueeditapp/components/SectionCourier.vueeditapp/components/SiteFooter.vue
githttps://jenkins.younex.de/user/infoinfofalse8https://jenkins.younex.de/job/blut24-landing/8/6https://jenkins.younex.de/job/blut24-landing/6/Started by GitHub push by younex162264c156533706f135d03479119c61e6af91fa0d2264c156533706f135d03479119c61e6af91fa0drefs/remotes/origin/main2264c156533706f135d03479119c61e6af91fa0d2264c156533706f135d03479119c61e6af91fa0drefs/remotes/origin/main2264c156533706f135d03479119c61e6af91fa0d2264c156533706f135d03479119c61e6af91fa0drefs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#6 2264c152654228038blut24-landing #6 2264c156false65451SUCCESS1785228290744https://jenkins.younex.de/job/blut24-landing/6/- app/pages/datenschutz.vue2264c156533706f135d03479119c61e6af91fa0d1785228279000https://jenkins.younex.de/user/infoinfoinfo@logyou.dedatenschutz: name the actual controller, matching the Impressum
Both pages must name the same responsible party or they contradict each other,
so the Verantwortlicher section now carries the same operator data as the
Impressum (Younes Kalakhi, IT Beratung & Dienstleistung, Lahnau) instead of
bracketed placeholders.
Two judgement calls, both noted in the file:
- the e-mail is still a placeholder because it is obfuscated on the source page
and could not be read; Art. 13 DSGVO requires a contact route, so it must be
filled before this is treated as live
- no Datenschutzbeauftragter is claimed - a freelancer of this size is generally
not required to appoint one under § 38 BDSG, and asserting one that does not
exist would be worse than saying none is appointed
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-28 10:44:39 +02002264c156533706f135d03479119c61e6af91fa0ddatenschutz: name the actual controller, matching the Impressumeditapp/pages/datenschutz.vue
githttps://jenkins.younex.de/user/infoinfofalse7https://jenkins.younex.de/job/blut24-landing/7/5https://jenkins.younex.de/job/blut24-landing/5/Started by GitHub push by younex159d957078b237f5dd9f22e2d14badac3ff8e33bd69d957078b237f5dd9f22e2d14badac3ff8e33bd6refs/remotes/origin/main9d957078b237f5dd9f22e2d14badac3ff8e33bd69d957078b237f5dd9f22e2d14badac3ff8e33bd6refs/remotes/origin/main9d957078b237f5dd9f22e2d14badac3ff8e33bd69d957078b237f5dd9f22e2d14badac3ff8e33bd6refs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#5 9d957072664528038blut24-landing #5 9d957075false55449SUCCESS1785227610682https://jenkins.younex.de/job/blut24-landing/5/- deploy/README.mdapp/app.vueapp/components/SectionHero.vueserver/api/registration/submit.post.tsapp/components/SiteFooter.vueapp/components/SiteHeader.vueapp/components/SectionRegistration.vueapp/pages/datenschutz.vueREADME.mdapp/components/SectionCourier.vue.idea/vcs.xmlapp/components/SectionApp.vueapp/components/RegistrationDialog.vueserver/utils/registrationValidation.tsscripts/test-registration.mjsapp/composables/useRegistrationDialog.tsserver/utils/registrationDb.tsapp/components/AndroidBadge.vueapp/components/AppIcon.vueapp/components/RegistrationForm.vuedeploy/nginx-blut24.confapp/components/SectionProof.vue9d957078b237f5dd9f22e2d14badac3ff8e33bd61785227601000https://jenkins.younex.de/user/infoinfoinfo@logyou.delanding: modal registration, value-led proof band, autocomplete fix, APK live
- Registration moved into a native <dialog> modal driven from every CTA, with
focus trap/return, scroll lock, backdrop + ESC dismissal, full-screen sheet on
mobile and prefers-reduced-motion respected.
- Replaced the data-source stats ("Quelle: Bundes-Klinik-Atlas", 293, 906) with
three statements of what the product actually does. No invented metrics: the
only figure left is the real 1.581 Klinik-Atlas count that was already there.
- Fixed the autocomplete staying open after a clinic was picked. Root cause was
watch(query): selecting wrote the label back into the field, which the watcher
read as a new search and reopened the list ~220ms later. The input is now
:value + @input so a programmatic write cannot be a search intent, with a
pendingQuery flag gating every path that opens the list.
- Removed Anrede end-to-end. The DB column is deliberately NOT migrated: it keeps
its NOT NULL DEFAULT '' so inserts that omit it stay valid on existing databases.
- Android badge switched live: the APK is published at
https://blut24.com/downloads/blut24-mobile.apk and served from disk by nginx
with the correct package MIME type.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-28 10:33:21 +02009d957078b237f5dd9f22e2d14badac3ff8e33bd6landing: modal registration, value-led proof band, autocomplete fix, APK liveeditapp/components/AppIcon.vueeditapp/components/SectionHero.vueeditapp/components/SiteFooter.vueeditapp/components/SiteHeader.vueeditserver/utils/registrationValidation.tseditapp/app.vueeditapp/components/SectionCourier.vueeditscripts/test-registration.mjseditdeploy/README.mdeditapp/components/RegistrationForm.vueadd.idea/vcs.xmleditapp/components/SectionProof.vueaddapp/components/RegistrationDialog.vueeditREADME.mdeditapp/components/SectionApp.vueeditapp/pages/datenschutz.vueeditdeploy/nginx-blut24.confaddapp/composables/useRegistrationDialog.tseditserver/api/registration/submit.post.tseditapp/components/SectionRegistration.vueeditserver/utils/registrationDb.tseditapp/components/AndroidBadge.vue
githttps://jenkins.younex.de/user/infoinfofalse6https://jenkins.younex.de/job/blut24-landing/6/4https://jenkins.younex.de/job/blut24-landing/4/Started by GitHub push by younex1488fb8db79ff790ff6f298d61b279dade9abc8b3b88fb8db79ff790ff6f298d61b279dade9abc8b3brefs/remotes/origin/main88fb8db79ff790ff6f298d61b279dade9abc8b3b88fb8db79ff790ff6f298d61b279dade9abc8b3brefs/remotes/origin/main88fb8db79ff790ff6f298d61b279dade9abc8b3b88fb8db79ff790ff6f298d61b279dade9abc8b3brefs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#4 88fb8db2625228038blut24-landing #4 88fb8db4false45446SUCCESS1785223605276https://jenkins.younex.de/job/blut24-landing/4/- app/components/SiteFooter.vueapp/components/AndroidBadge.vueapp/components/SectionApp.vue88fb8db79ff790ff6f298d61b279dade9abc8b3b1785223594000https://jenkins.younex.de/user/infoinfoinfo@logyou.delanding: proper Android download badge, reused in the footer
Replaces the flat outline-icon button with a badge in the visual language people
actually recognise: dark pill, mark on the left, small kicker over a bold line,
and the Android robot drawn inline in its own green (#3DDC84).
Deliberately NOT the official "Get it on Google Play" badge. That artwork is
Google's trademark and licensed only for links pointing at a Play Store listing;
this link is a direct APK download, so copying it would be both a trademark
problem and a false claim to the visitor. Same recognition, honest wording
("Direkt-Download / Android APK").
Extracted as AndroidBadge.vue with a `compact` variant so the app section and the
footer cannot drift apart. Until an APK exists the badge renders as a disabled
span (not a dead link) with its own aria-label; set `available` to switch it on.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-28 09:26:34 +020088fb8db79ff790ff6f298d61b279dade9abc8b3blanding: proper Android download badge, reused in the footeraddapp/components/AndroidBadge.vueeditapp/components/SiteFooter.vueeditapp/components/SectionApp.vue
githttps://jenkins.younex.de/user/infoinfofalse5https://jenkins.younex.de/job/blut24-landing/5/3https://jenkins.younex.de/job/blut24-landing/3/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/Started by GitHub push by younex1Started by GitHub push by younex1Started by an SCM changeStarted by an SCM change2679906e5db227bfa0d8a3ca5800418269ab474e8679906e5db227bfa0d8a3ca5800418269ab474e8refs/remotes/origin/main679906e5db227bfa0d8a3ca5800418269ab474e8679906e5db227bfa0d8a3ca5800418269ab474e8refs/remotes/origin/main679906e5db227bfa0d8a3ca5800418269ab474e8679906e5db227bfa0d8a3ca5800418269ab474e8refs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#2 679906e3275028038blut24-landing #2 679906e2false25442SUCCESS1785218932906https://jenkins.younex.de/job/blut24-landing/2/- deploy/deploy.shdeploy/bootstrap-server.shdeploy/ecosystem.config.cjs679906e5db227bfa0d8a3ca5800418269ab474e81785218244000https://jenkins.younex.de/user/infoinfoinfo@logyou.dedeploy: pin Node v22.22.3, self-heal the install, realign bootstrap to ISPConfig
The first Jenkins build logged EBADENGINE warnings: several transitive deps
(@babel/*, undici) require Node ^22.18 / >=22.19 while the pin was v22.14.0.
Bumped to v22.22.3 — same NODE_MODULE_VERSION 127, so the better-sqlite3 native
build stays compatible and no rebuild-from-scratch is forced.
deploy.sh now runs `nvm install` rather than `nvm use`, so bumping the pin in git
is sufficient; previously a new version would have failed the deploy outright with
"N/A: version not yet installed". It also ensures pm2 exists for that Node build.
bootstrap-server.sh still carried the pre-ISPConfig layout and, worse, would have
written a standalone nginx vhost with the same server_name as the ISPConfig-generated
one - a collision that ISPConfig would regenerate away. It now creates the real
layout (code in the docroot, secrets and SQLite in the site's private/ dir) and only
REPORTS on the proxy block instead of fighting the panel for ownership.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-28 07:57:24 +0200679906e5db227bfa0d8a3ca5800418269ab474e8deploy: pin Node v22.22.3, self-heal the install, realign bootstrap to ISPConfigeditdeploy/deploy.sheditdeploy/bootstrap-server.sheditdeploy/ecosystem.config.cjs
githttps://jenkins.younex.de/user/infoinfofalse3https://jenkins.younex.de/job/blut24-landing/3/1https://jenkins.younex.de/job/blut24-landing/1/Started by GitHub push by younex11091770a6c5138113b51582d5bd5e86c607cbe262091770a6c5138113b51582d5bd5e86c607cbe262refs/remotes/origin/main091770a6c5138113b51582d5bd5e86c607cbe262091770a6c5138113b51582d5bd5e86c607cbe262refs/remotes/origin/main091770a6c5138113b51582d5bd5e86c607cbe262091770a6c5138113b51582d5bd5e86c607cbe262refs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#1 091770a3025428038blut24-landing #1 091770a1false15439SUCCESS1785192514932https://jenkins.younex.de/job/blut24-landing/1/false2https://jenkins.younex.de/job/blut24-landing/2/blueStarted by GitHub push by younex11091770a6c5138113b51582d5bd5e86c607cbe262091770a6c5138113b51582d5bd5e86c607cbe262refs/remotes/origin/main091770a6c5138113b51582d5bd5e86c607cbe262091770a6c5138113b51582d5bd5e86c607cbe262refs/remotes/origin/main091770a6c5138113b51582d5bd5e86c607cbe262091770a6c5138113b51582d5bd5e86c607cbe262refs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#1 091770a3025428038blut24-landing #1 091770a1false15439SUCCESS1785192514932https://jenkins.younex.de/job/blut24-landing/1/false2https://jenkins.younex.de/job/blut24-landing/2/Build stability: No recent builds failed.icon-health-80plushealth-80plus.png100falseStarted by GitHub push by younex11549f3d63e2f1169fda0b321572605cb5f9b6fcd5e49f3d63e2f1169fda0b321572605cb5f9b6fcd5erefs/remotes/origin/main49f3d63e2f1169fda0b321572605cb5f9b6fcd5e49f3d63e2f1169fda0b321572605cb5f9b6fcd5erefs/remotes/origin/main49f3d63e2f1169fda0b321572605cb5f9b6fcd5e49f3d63e2f1169fda0b321572605cb5f9b6fcd5erefs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#15 49f3d633060428038blut24-landing #15 49f3d6315false155476SUCCESS1785257388243https://jenkins.younex.de/job/blut24-landing/15/- app/locales/de.tsscripts/test-registration.mjsserver/api/registration/confirm.post.tsserver/utils/i18n.tsapp/locales/en.tsREADME.md49f3d63e2f1169fda0b321572605cb5f9b6fcd5e1785257378000https://jenkins.younex.de/user/infoinfoinfo@younex.deregistration: keep the manual-review promise — gate ERP onboarding on needs_manual_approval
HANDOFF §4 (ERP repo, reference/blut24/HANDOFF.md). needs_manual_approval gated
nothing: couriers and no-domain clinics — exactly the registrations nothing
could verify — were auto-onboarded into iDempiere with live credentials mailed,
while form, confirmation mail and welcome mail promised a manual review.
confirm.post.ts now skips onboarding for them and records erp_status
'manual-approval'; the operator provisions them by hand. Verified and test
registrations stay fully automatic.
Copy made truthful: the test-domain notice no longer claims "marked for manual
approval" (test domains auto-activate; they are marked internally as test
registrations), and the manual-review texts are courier-neutral instead of
explaining a clinic-only domain lookup.
alreadyConfirmed now returns credentialsSent, read from the stored ERP payload
(setErpResult persists it).
README: the ERP auth section described a Bearer scheme the code never uses —
the token travels as the logship_it cookie, and the ERP's send-credentials
route is now gated on exact equality with the instance's IDEMPIERETOKEN, so
ERP_SERVICE_TOKEN must be exactly that value.
test-registration.mjs: courier confirm asserts needsManualApproval,
credentialsSent=false and erp_status 'manual-approval' (83/83 green).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-28 18:49:38 +020049f3d63e2f1169fda0b321572605cb5f9b6fcd5eregistration: keep the manual-review promise — gate ERP onboarding on needs_manual_approvaleditscripts/test-registration.mjseditapp/locales/en.tseditREADME.mdeditapp/locales/de.tseditserver/api/registration/confirm.post.tseditserver/utils/i18n.ts
githttps://jenkins.younex.de/user/infoinfofalse14https://jenkins.younex.de/job/blut24-landing/14/Started by GitHub push by younex11549f3d63e2f1169fda0b321572605cb5f9b6fcd5e49f3d63e2f1169fda0b321572605cb5f9b6fcd5erefs/remotes/origin/main49f3d63e2f1169fda0b321572605cb5f9b6fcd5e49f3d63e2f1169fda0b321572605cb5f9b6fcd5erefs/remotes/origin/main49f3d63e2f1169fda0b321572605cb5f9b6fcd5e49f3d63e2f1169fda0b321572605cb5f9b6fcd5erefs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#15 49f3d633060428038blut24-landing #15 49f3d6315false155476SUCCESS1785257388243https://jenkins.younex.de/job/blut24-landing/15/- app/locales/de.tsscripts/test-registration.mjsserver/api/registration/confirm.post.tsserver/utils/i18n.tsapp/locales/en.tsREADME.md49f3d63e2f1169fda0b321572605cb5f9b6fcd5e1785257378000https://jenkins.younex.de/user/infoinfoinfo@younex.deregistration: keep the manual-review promise — gate ERP onboarding on needs_manual_approval
HANDOFF §4 (ERP repo, reference/blut24/HANDOFF.md). needs_manual_approval gated
nothing: couriers and no-domain clinics — exactly the registrations nothing
could verify — were auto-onboarded into iDempiere with live credentials mailed,
while form, confirmation mail and welcome mail promised a manual review.
confirm.post.ts now skips onboarding for them and records erp_status
'manual-approval'; the operator provisions them by hand. Verified and test
registrations stay fully automatic.
Copy made truthful: the test-domain notice no longer claims "marked for manual
approval" (test domains auto-activate; they are marked internally as test
registrations), and the manual-review texts are courier-neutral instead of
explaining a clinic-only domain lookup.
alreadyConfirmed now returns credentialsSent, read from the stored ERP payload
(setErpResult persists it).
README: the ERP auth section described a Bearer scheme the code never uses —
the token travels as the logship_it cookie, and the ERP's send-credentials
route is now gated on exact equality with the instance's IDEMPIERETOKEN, so
ERP_SERVICE_TOKEN must be exactly that value.
test-registration.mjs: courier confirm asserts needsManualApproval,
credentialsSent=false and erp_status 'manual-approval' (83/83 green).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-28 18:49:38 +020049f3d63e2f1169fda0b321572605cb5f9b6fcd5eregistration: keep the manual-review promise — gate ERP onboarding on needs_manual_approvaleditscripts/test-registration.mjseditapp/locales/en.tseditREADME.mdeditapp/locales/de.tseditserver/api/registration/confirm.post.tseditserver/utils/i18n.ts
githttps://jenkins.younex.de/user/infoinfofalse14https://jenkins.younex.de/job/blut24-landing/14/Started by GitHub push by younex11549f3d63e2f1169fda0b321572605cb5f9b6fcd5e49f3d63e2f1169fda0b321572605cb5f9b6fcd5erefs/remotes/origin/main49f3d63e2f1169fda0b321572605cb5f9b6fcd5e49f3d63e2f1169fda0b321572605cb5f9b6fcd5erefs/remotes/origin/main49f3d63e2f1169fda0b321572605cb5f9b6fcd5e49f3d63e2f1169fda0b321572605cb5f9b6fcd5erefs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#15 49f3d633060428038blut24-landing #15 49f3d6315false155476SUCCESS1785257388243https://jenkins.younex.de/job/blut24-landing/15/- app/locales/de.tsscripts/test-registration.mjsserver/api/registration/confirm.post.tsserver/utils/i18n.tsapp/locales/en.tsREADME.md49f3d63e2f1169fda0b321572605cb5f9b6fcd5e1785257378000https://jenkins.younex.de/user/infoinfoinfo@younex.deregistration: keep the manual-review promise — gate ERP onboarding on needs_manual_approval
HANDOFF §4 (ERP repo, reference/blut24/HANDOFF.md). needs_manual_approval gated
nothing: couriers and no-domain clinics — exactly the registrations nothing
could verify — were auto-onboarded into iDempiere with live credentials mailed,
while form, confirmation mail and welcome mail promised a manual review.
confirm.post.ts now skips onboarding for them and records erp_status
'manual-approval'; the operator provisions them by hand. Verified and test
registrations stay fully automatic.
Copy made truthful: the test-domain notice no longer claims "marked for manual
approval" (test domains auto-activate; they are marked internally as test
registrations), and the manual-review texts are courier-neutral instead of
explaining a clinic-only domain lookup.
alreadyConfirmed now returns credentialsSent, read from the stored ERP payload
(setErpResult persists it).
README: the ERP auth section described a Bearer scheme the code never uses —
the token travels as the logship_it cookie, and the ERP's send-credentials
route is now gated on exact equality with the instance's IDEMPIERETOKEN, so
ERP_SERVICE_TOKEN must be exactly that value.
test-registration.mjs: courier confirm asserts needsManualApproval,
credentialsSent=false and erp_status 'manual-approval' (83/83 green).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-28 18:49:38 +020049f3d63e2f1169fda0b321572605cb5f9b6fcd5eregistration: keep the manual-review promise — gate ERP onboarding on needs_manual_approvaleditscripts/test-registration.mjseditapp/locales/en.tseditREADME.mdeditapp/locales/de.tseditserver/api/registration/confirm.post.tseditserver/utils/i18n.ts
githttps://jenkins.younex.de/user/infoinfofalse14https://jenkins.younex.de/job/blut24-landing/14/Started by GitHub push by younex11549f3d63e2f1169fda0b321572605cb5f9b6fcd5e49f3d63e2f1169fda0b321572605cb5f9b6fcd5erefs/remotes/origin/main49f3d63e2f1169fda0b321572605cb5f9b6fcd5e49f3d63e2f1169fda0b321572605cb5f9b6fcd5erefs/remotes/origin/main49f3d63e2f1169fda0b321572605cb5f9b6fcd5e49f3d63e2f1169fda0b321572605cb5f9b6fcd5erefs/remotes/origin/mainhttps://github.com/younex1/blut24-landing.gitfalse#15 49f3d633060428038blut24-landing #15 49f3d6315false155476SUCCESS1785257388243https://jenkins.younex.de/job/blut24-landing/15/- app/locales/de.tsscripts/test-registration.mjsserver/api/registration/confirm.post.tsserver/utils/i18n.tsapp/locales/en.tsREADME.md49f3d63e2f1169fda0b321572605cb5f9b6fcd5e1785257378000https://jenkins.younex.de/user/infoinfoinfo@younex.deregistration: keep the manual-review promise — gate ERP onboarding on needs_manual_approval
HANDOFF §4 (ERP repo, reference/blut24/HANDOFF.md). needs_manual_approval gated
nothing: couriers and no-domain clinics — exactly the registrations nothing
could verify — were auto-onboarded into iDempiere with live credentials mailed,
while form, confirmation mail and welcome mail promised a manual review.
confirm.post.ts now skips onboarding for them and records erp_status
'manual-approval'; the operator provisions them by hand. Verified and test
registrations stay fully automatic.
Copy made truthful: the test-domain notice no longer claims "marked for manual
approval" (test domains auto-activate; they are marked internally as test
registrations), and the manual-review texts are courier-neutral instead of
explaining a clinic-only domain lookup.
alreadyConfirmed now returns credentialsSent, read from the stored ERP payload
(setErpResult persists it).
README: the ERP auth section described a Bearer scheme the code never uses —
the token travels as the logship_it cookie, and the ERP's send-credentials
route is now gated on exact equality with the instance's IDEMPIERETOKEN, so
ERP_SERVICE_TOKEN must be exactly that value.
test-registration.mjs: courier confirm asserts needsManualApproval,
credentialsSent=false and erp_status 'manual-approval' (83/83 green).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-28 18:49:38 +020049f3d63e2f1169fda0b321572605cb5f9b6fcd5eregistration: keep the manual-review promise — gate ERP onboarding on needs_manual_approvaleditscripts/test-registration.mjseditapp/locales/en.tseditREADME.mdeditapp/locales/de.tseditserver/api/registration/confirm.post.tseditserver/utils/i18n.ts
githttps://jenkins.younex.de/user/infoinfofalse14https://jenkins.younex.de/job/blut24-landing/14/16truefalsefalse