8 Commits (32016d9b80184427da3e6ec1b277ea022a2706cb)

Author	SHA1	Message	Date
nexxo	b32c6fc33f	Sell the year as well as the month, and say what it saves ... Both prices have existed since the catalogue did — one `plan_prices` row per term, each with its own Stripe Price, and the checkout has taken a `term` all along. Nothing ever sent one. The shop showed the monthly figure, the order page posted no term, and the yearly Price sat there being paid for by nobody. **The console asks for free months, not a second price.** It used to take the yearly TOTAL as its own free-form figure, so nothing in the system knew WHY 588 belonged to a package costing 49 a month — and no page could say "zwei Monate gratis" without a person working it out again and writing it somewhere it would then drift. Now: the monthly price and how many of the twelve months are free. The total is derived from the two (PlanVersions::yearlyCents), previewed live on the form, and written to the catalogue from the same arithmetic. `free_months` sits on the VERSION, beside the capabilities publication freezes, because that is what it is — part of the terms a customer bought. The migration reads it back out of the prices that already exist rather than defaulting to nought: an installation selling twelve-for-ten must not lose that on a deploy. Only an exact division counts; a hand-negotiated yearly figure keeps its amount and simply goes unexplained. **The customer chooses.** A switch on the order page and on the public sheet, both figures rendered and one shown, so switching costs no request. The headline stays "per month" in either term — a yearly total as one big number reads as five times dearer at a glance — with the amount actually taken, the net figure, the months free and what twelve monthly payments would have cost underneath. The form posts the term the customer was looking at, and the checkout picks that term's Stripe Price. The billing card now says which term is running. It states a monthly figure whatever the term, so a yearly customer was reading a number that never appears on a statement. Also: **a Blade comment must never spell a directive.** Blade compiles what is inside `{{-- --}}` too — the comment is stripped from the output, but its directives are compiled on the way there. A comment explaining why the parenthesised php directive had been avoided produced exactly the open PHP tag it warned about, and the rest of the file was swallowed as PHP source: no exception, no warning, the page one block short. That is how the term switch vanished after being written. BladeCommentsTest scans for the forms that open a tag. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:44:35 +02:00
nexxo	d4e8822dbb	Paketversionen: Verkauf wieder aufnehmen und saubere Übergabe ... Eine geschlossene Version konnte nie wieder in den Verkauf. Schlimmer: um ein Paket zu ändern, musste die laufende Version zuerst beendet werden — und wenn die Nachfolgerin dann nicht sofort veröffentlicht wurde, war das Paket dauerhaft dunkel. - PlanCatalogue::reopen() setzt available_until zurück auf null, über schedule(), damit Family-Lock und Überlappungsprüfung dieselben bleiben. Ein nie veröffentlichter Entwurf wird abgelehnt. - PlanCatalogue::publish() übergibt eine laufende Version an ihre Nachfolgerin (available_until = deren Start) statt die Überlappung abzulehnen — unter demselben Lock, in derselben Transaktion. Nur die unmittelbare Vorgängerin, und nur wenn es genau eine gibt. - Konsole: Knopf „Wieder verkaufen", übersetzte Ablehnung statt der englischen Ausnahme, und die Übergabe wird im Veröffentlichen-Formular vorher angekündigt (Version und Zeitpunkt, ->local()). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 14:58:11 +02:00
nexxo	8c105c17d6	Move each plan's marketing copy from the controller into the console ... Audience line and note were LandingController::COPY, a hardcoded array keyed on exactly the four plan keys the seed migration created — a plan made under any other key rendered with no copy at all. They move onto the family for the same reason the recommendation mark does: they are a stance about the product line, not a capability that changes with a price, so they must not be frozen per version. Backfilled in the migration from the controller's own strings, so the public page prints exactly what it printed a moment ago. A family with no copy yet renders without the audience line rather than an empty gap. Feature labels (managed_updates, daily_backups, ...) stay in the controller: they name catalogue features, not individual plans, so there is no per-plan or per-version place to hang an editable customer-facing label without re-introducing a shared feature table. That table existed once and was deliberately removed when the plan catalogue closed its pricing split-brain; bringing it back for wording alone is a bigger, separate decision.	2026-07-29 14:31:44 +02:00
nexxo	4ef5b9519c	Let the owner mark one plan as recommended, from the console ... Recommended lives on the plan family, not a version: it is a stance about the product line ("which plan we point a visitor towards"), not a capability that changes with a price, and freezing it per version would make the mark silently vanish every time a new version publishes. Setting a plan recommended clears whichever other plan carried the mark, inside one transaction locking the whole table — two operators recommending two different plans at once must not both win. The public price sheet already had the highlighted-card treatment for this (it was driven by a hardcoded "team" constant); it now reads the family instead.	2026-07-29 14:22:22 +02:00
nexxo	87c49de6e5	Move the console's identity out of the customer table	2026-07-28 10:31:43 +02:00
nexxo	bd779f00e5	Show times on the operator's clock, keep storing them in UTC ... The console announced an update for "spätestens um 15:21" while the clock on the wall said 17:21. Not a formatting slip in one string: fourteen views and four components printed database values straight out, so every absolute time in the product was two hours out all summer and one hour out all winter. Two of those views looked as though they had handled it. They called ->timezone(config('app.timezone')) which reads like "convert to local time" and, app.timezone being the STORAGE zone that must stay UTC, converts to UTC — a no-op wearing the costume of a fix, which is worse than no call at all because it stops the next person looking. That exact string is now banned by test. Worse than the labels were two FORMS. Maintenance windows and plan versions filled their datetime-local fields from UTC and parsed what came back as UTC. A datetime-local field carries no offset — it is the digits a person reads off their own clock — so an operator typing 21:00 scheduled a window for 23:00 their time, and nothing anywhere said so. App\Support\LocalTime now holds toField() and fromField() side by side, because getting one end right is not half a fix, it is a fresh bug. The mechanism is one Carbon macro, ->local(). It copies before converting: Illuminate\Support\Carbon is mutable, so without that, rendering a timestamp would rewrite the model attribute as a side effect and anything comparing or saving it afterwards would be an hour or two out. Both Carbon classes get the same body — Carbon keeps macros in one global table, so the second registration replaces the first for every Carbon class, and two different bodies meant the immutable version, safe for itself, silently became the mutable one's implementation too. My own test caught that. The existing tests had not caught any of this because they built their expected values with the same wrong call the views used — a test that recomputes the implementation asserts nothing. They now assert the wall clock, and the queued update additionally asserts that the UTC time is NOT shown. Recorded as R19 in CLAUDE.md and enforced by tests/Feature/DisplayTimezoneTest: no Blade or Livewire component may format an absolute time without ->local(), the UTC no-op is banned, storage stays UTC, both sides of the DST boundary are checked, ->local() must not mutate, and a form field must round-trip to the same instant. APP_DISPLAY_TIMEZONE, default Europe/Vienna. 615 tests. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 17:32:21 +02:00
Claude	bc8bbc56a5	Make the console's access list reach the proxy, price in euros, and answer errors ... The console was unreachable, and not for the reason it looked like. Two causes, both mine. A failed `artisan optimize` — the one that hit duplicate route names — left a broken route cache behind, so every request to the console host answered 500. Rebuilt. Underneath that: the reverse proxy has its own console allowlist, hard-coded, and it runs BEFORE the application. Everything added on the console's own access page was therefore ineffective, and when the owner's address changed they were turned away by the proxy before reaching the page that would have fixed it. The proxy now imports a fragment generated from the same list the console manages, regenerated by the host agent and reloaded when it changes. Getting that safe took most of the review. It refuses to rewrite an ambiguous Caddyfile rather than replacing some other site's matcher; it never falls back to a loopback-only list when the application cannot be reached, because that list validates cleanly and locks out every remote operator; it retries a reload that failed instead of assuming it worked; and an installation that upgrades without rerunning the installer is told, because otherwise the whole mechanism is invisibly absent. Prices are entered in euros. The form asked for cents, so €799 was typed as 79900 and one slipped digit was a factor of ten on an invoice. Conversion happens in one place, on the string rather than through a float — (float) '79.90' × 100 is 7989.999… and casting truncates to 7989, one cent short on exactly the prices people charge — and it refuses an amount the column cannot hold instead of failing at the database. Every error code has a page now, in the site's own language and typeface, self-contained so it still renders when the asset manifest is the thing that broke. There was only a bare white 404. The VPN list stops being a seven-column table nobody could fit: names broke across two lines and so did the headings. These are attributes of one access, not quantities compared down a column, so each access is a row — identity on one line, measurements in mono on the next. The status page says what it measures rather than what it promises. "New orders are delivered without failures" read as a marketing claim on a page whose only job is to be believed, and said nothing about the last 24 hours. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 06:51:05 +02:00
nexxo	f6ddf45dc0	feat(admin): a console for creating, pricing and scheduling plans ... The owner can now do from the console what only a config edit could do before: create a plan line, draft a version, price it, publish it into a window, and pull a plan out of the shop. Two pages and one modal, because the catalogue has exactly two levels. The plan list is a name, a rank and a kill switch. Everything that can be got wrong — capabilities, prices, windows — lives on the versions, where the page is built around the one rule that matters: a draft is freely editable, a published version is not touchable at all. So drafting and publishing are separate acts, and publishing says plainly that it is final. The console refuses everything the catalogue refuses, on the form rather than as a stack trace: an overlapping window, a window that ends before it starts, a version with no price for a term we sell on, and — new here — a version with no VM template, which would be bought and then fail provisioning every time. Numbers are bounded on both sides, because a mistyped price otherwise overflows the column and answers with a 500 instead of saying which field was wrong. Performance class and features are picked from the keys we have labels for; free text would be frozen at publication and shown to customers as a raw translation key forever. Concurrency, since two admins share one catalogue: draft numbers are allocated under a lock on the family, publication is an atomic conditional claim, and discarding a draft is one statement conditional on it still being a draft — otherwise a draft published in the meantime could be deleted out from under the customers now contracted to it. `plans.manage` (Owner and Admin) guards the pages themselves, not only the buttons, and the modal authorises itself — prices, drafts and unreleased plans are not something to leave readable to anyone who types the URL. Also fixes the shared checkbox, which ticked in the browser's own blue on every page that used one: a native checkbox ignores text colour and needs accent-color. Verified in the browser: withdrawing a plan in the console removes it from the customer's billing page immediately, and restoring it brings it back. The public landing page carries no catalogue-driven plan list, so there is nothing there to hide. 421 tests green. Codex review clean after six rounds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 12:41:51 +02:00