158 Commits (feature/host-bootstrap)

Author	SHA1	Message	Date
nexxo	cfaea7dc82	Fill the hostname page from the installation, not from a blank form ... The page was empty, and that was a design fault rather than a missing button. I built a register that starts blank — while the installation already serves half a dozen names whose certificates were exactly what the operator wanted to see. An overview you have to populate first does not answer "what do I have". So the names are derived now, from the same configuration routes/web.php builds its domain bindings from: SITE_HOSTS, APP_HOST, FILES_HOST, ADMIN_HOSTS. If a name is in the environment, the application answers on it, and then it belongs in this list without anybody typing it a second time. Opening the page syncs them; the list is never empty again. Syncing and measuring are deliberately separate. The sync costs nothing and runs on page load. The measurement goes out over the network and runs on the button or on a schedule — doing it on page load would mean waiting through half a dozen TLS handshakes, and one of them is always the name that currently does not resolve. Which is the other half of what was missing: there was no overview because nothing measured unless somebody pressed a button. A daily run at 04:17 fills it, because the question that matters is not "is it valid right now" but "is renewal running" — a certificate expiring in forty days is fine, the same one at twenty means something has been broken for a week. Only a measurement taken while nobody is looking can tell those apart. The page now opens with four counts — total, valid, expiring soon, without a certificate — and says when it last measured. A name that comes from the environment is marked as such and cannot be removed here: it would come back at the next sync, and a button that does nothing is worse than no button, because it gets believed once. 2040 tests pass, assets build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 00:53:12 +02:00
nexxo	006ce3568b	Manage hostnames and watch their certificates from the console ... files.clupilot.com is why this exists. DNS pointed at the right machine, the env var was set, the release was deployed — and there was still no certificate, because /etc/caddy/Caddyfile is maintained by hand and nobody thought of it as a second, separate step. Nothing in the console would have said so. Three settings looked correct and the address did not answer. So the page holds two things side by side. The WISH — which names should be served — and the REALITY: whether the name has a certificate and for how much longer. The second is measured by opening a TLS connection and reading the expiry, not by reading configuration, because the configuration is exactly what looked right while the address was dead. verify_peer stays on: a certificate that fails validation is not a certificate for this question, and a display that called it valid would be the fake R19 records. Applying goes through the existing agent, not a new channel. The console writes a request, the path unit wakes the agent within a second, and the agent calls one fixed command line of the root-owned helper. What that helper is allowed to do is the careful part. It fetches the list ITSELF rather than being handed one, and the list is HOSTNAMES, never Caddy blocks — `php artisan clupilot:proxy-hosts` prints `<name> <purpose>` and nothing else. Each name is matched against a strict pattern before it is used, and the template around it lives in the helper, which the service account cannot touch. install-agent.sh already states the principle for the sudoers grant: a grant is only worth anything if the holder cannot change what it grants. A service account that could write proxy configuration would have everything the proxy can do — redirects anywhere, files from any directory. Purpose is a column rather than a habit. A console name gets the network lock, a public one does not, and a console name published without it looks exactly like a working page. Removing takes the name out of the list and NOT out of the running proxy. Two decisions in one click, and the second one takes a site off the air. There is deliberately no "renew" button. Caddy renews on its own at two thirds of the lifetime; what an operator actually needs is a second attempt after an issuance has failed, and that is a reload — which is what Apply does. Thirty days is treated as a problem rather than a warning: at ninety days' lifetime, a renewal should long since have run, so anything under it is not a tight certificate but a renewal that is not happening. The ACME contact falls back to the owner's address, because a contact nobody reads is the step before expired customer certificates. CONTRACT and HOST_STEP_NEEDS both move to 2, which is what tells a server carrying the older helper to run the installer again — caught by the guard test that compares the two halves. 2035 tests pass, assets build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 22:55:55 +02:00
nexxo	2194ab8079	Put the instructions where somebody reads them before they start ... The previous commit shipped the guide AFTER the host was created. Its first two steps happen at the provider — order the machine, boot the rescue system — and whoever reads them there has the one-time code already in the clipboard with its 24-hour window running. The instructions were correct and in the wrong place, which is its own kind of wrong. Six steps now, not three, and the two provider ones are named rather than assumed. They are marked "first" so the list does not read as something you can start at the top of and work down: step 2 is half an hour of waiting, and doing it inside a running code is exactly the mistake the page should prevent. All six are visible the whole time, including the done ones and the ones still to come. A guide that shows only the current step cannot answer "how much is left", which is the question somebody has while a server they are paying for sits in a rescue system. It is on the hosts list too, collapsed. Somebody standing there may not have ordered the machine yet — and that is step 1. Requiring them to click "add host" to find out what the procedure is puts the answer behind the action it describes. One component, two places, so the archive address in the instructions is the same string the command line will carry. Two copies of that would drift, and the difference would surface on a server that has already been paid for. The step-4 command box moved into the guide rather than sitting beside it, so after creating a host the whole procedure stays on screen. Somebody stuck at step 5 should not be looking at a page that has become a single box. 1991 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 20:51:47 +02:00
nexxo	903ebdd2b2	Give the operator one line to copy and three steps around it ... The console could describe a takeover it had no way to start. This is the vertical slice that closes that: a one-time code, the archive the rescue system fetches, and the page that says what to do with both. The command carries EVERYTHING the script needs before the tunnel exists, because there is nothing to fetch — that is the whole point of spec §5. Which means CluPilot generates the WireGuard keypair and admits the peer at the hub before the machine has ever booted, and hands the private half over in the line. It is worthless within minutes: task 9 of the script replaces it with one generated on the machine. Shown exactly once. The database holds only the code's hash and never the private key, so leaving the page does not bring it back — it mints a new code, which invalidates the old one. That is deliberate: a glance at somebody's screen should be worth nothing an hour later. Which is also why save() no longer redirects. Sending the operator to the host detail page sends them away from the only value they need, and an existing test asserted that redirect — it now asserts the opposite, with the reason written next to it. SHA-256 rather than bcrypt for the code, and the reason is not speed. Both endpoints have to FIND the host by the code; with bcrypt that means trying every row. The code is 32 characters of CSPRNG output, so it has the entropy that stretching exists to manufacture. resolve() and claim() are separate because progress reports arrive BEFORE registration. If reporting consumed the code, a host could never register after its first message. The archive URL is always the public hostname. The console runs under admin.…, but this line executes on a machine that must not reach the admin area — it is locked down for exactly that reason — so route() from the console would emit a hostname that 404s on a server only reachable through the provider's console. The page warns about missing tunnel settings BEFORE the host is created, not after. An empty hub key produces a line that looks clean, copies fine, runs, and ends in a tunnel that never handshakes — discovered on the machine, after somebody has already paid for it. The three steps lead with the rescue system, because that is the one nobody knows by heart, and it says enabling is not the same as booting into it — the script refuses a running production machine, which is what a half-done switch looks like from the inside. 1986 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 20:40:19 +02:00
nexxo	880b5f1998	Merge main into the operating-mode branch ... Three real conflicts, and one file that did not conflict and mattered more. Overview::notices(): both sides added notices. Kept all of them, and pointed main's mail check at MailboxTransport::NON_DELIVERING — its own comment already named the constant while the code carried a copy of the list. billing.blade.php: main wrapped the page in a contract branch. The "payment is not set up" error moved OUTSIDE it, because the customer most likely to meet that message is the one buying for the first time, who has no contract yet and would never have seen it from inside the @else. ConsoleReportsRealDataTest: kept both sides rather than choosing. The renamed test and its docblock explain why admin.systems_ok can no longer be asserted on a bare install; main's mail pin still keeps "clean" clean in the mail dimension. Picking one would have quietly weakened the other's claim. HostStepsTest: git combined main's config()->set('provisioning.dns.zone', 'clupilot.com') with this branch's assertion on clupilot.cloud, and produced a test that contradicted itself with no marker. Main's approach is the better one — it pins the zone in the test and asserts the SHAPE of the name rather than this box's domain — so its assertion stands. HttpStripeClient merged silently and correctly: secret() still throws, isConfigured() still reads the vault directly. Had it taken main's filled($this->secret()), six callers that ask in order NOT to get an exception would have become exception throwers, and the suite would have stayed green. CheckoutWithoutStripeKeyTest is the lock that would have caught it. StripeIdempotencyKeyTest (new on main) leaned on the environment fallback for stripe.secret. That entry is strict now — no fallback in either direction, so the .env cannot be a back door for a live key in test mode. It stores a real vault row instead. 1966 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:53:20 +02:00
nexxo	52aacddc56	Store the agreement where the web process can actually read it ... Every link on the agreement page answered 404 — the download visibly, the two inline ones just as dead — and nothing anywhere said why. The files were there, whole and correct. An artisan run inside a container is root; PHP-FPM is www-data. Laravel's local disk creates a PRIVATE directory, which is 0700, so `dpa/` came out as root-only. The web process could not enter it, `Storage::exists()` answered false, and the routes did exactly what they were told: abort 404. No exception, no log line, a page full of links to nothing. Both writers — the command and the console's upload form — now store with "public" visibility, which is the file MODE and nothing to do with the web: 0755/0644 instead of 0700/0600. The disk's root is outside the document root either way, and the two routes still check who is asking. The command also warns if a file it just wrote is not readable, because the alternative is finding out from a customer. The download itself now looks like one: the `download` attribute on both anchors, and in the console a bordered control rather than a third link in a row of two. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:19:39 +02:00
nexxo	955f1b874f	Deliver the processing agreement, and hold the proof it was accepted ... Art. 28(3) GDPR wants a contract wherever personal data is processed on somebody else's behalf, which is the whole of what this product does. "In writing" there includes electronic form (Art. 28(9)), so a document the customer can read plus a recorded acceptance is enough — no signature on paper. The website already promises "AV-Vertrag inklusive", which means it has to be obtainable without asking us for it. It was not obtainable at all. **The text is never this application's.** An operator uploads the document their lawyer wrote, names the version, and publishes it; the measures ride along as a second file, because they are an annex to the agreement and "which measures applied when this customer accepted" has to have one answer. Inventing the text here would have been worse than having none. **Uploading and publishing are two acts.** Acceptance is per version, so publishing leaves every customer who accepted the previous one outstanding again — correct, and far too expensive to trigger by dropping a file on a form. It goes through a confirmation modal that says exactly that (R23). **The customer's side** is a card in the contract tab: read the agreement, read the measures, one press to conclude it. What that press records is what makes it evidence rather than a flag — the version, the moment, the address it came from, and the login that pressed. Pressing twice is one agreement (unique index, not a check somebody can forget), and a superseded acceptance is kept rather than overwritten: it was true when it was made, and the history is the point. Nothing renders until a version is in force. A card offering an agreement that does not exist is worse than the silence. The files live on the private disk and are served through routes that check who is asking — an agreement is not a public asset, and a guessable URL to one would be a list of who our customers are. The customer route takes no version parameter: which document applies is ours to say. `dpa.manage` is its own capability on the OPERATOR guard. Whoever keeps the platform running does not thereby decide what every customer is asked to agree to — and a capability written under `web` since the 2026-07-29 move lands in a guard nothing authenticates against, which is how this one first shipped answering 403 to a role that visibly had it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:56:57 +02:00
nexxo	1056dddc62	Take the address by field, fix the customer type, ask why they leave ... **The billing address was one textarea**, so what landed in it was whatever somebody typed: a postcode on the street line, a city with no postcode, no country at all. It is four fields now — street, postcode, town, country — in the customer's settings and in the console's customer editor, which had its own free-text copy of the same field and would have had an operator's correction silently reverted the next time the customer saved. `customers.billing_address` is neither dropped nor parsed: guessing which line of an existing block is the street would put a postcode where a street belongs on a document nobody can correct afterwards. It becomes the COMPOSED form, rewritten from the fields on every save, so IssueInvoice and everything else that reads it keep working, and a record nobody has re-saved keeps the block it always had. **The customer type is fixed once it is on record.** It decides the fourteen-day right of withdrawal, and a business able to set itself to "Privatperson" on this page is a business able to withdraw from a contract it may not withdraw from. Registration asks the question; this page reports the answer, and saveProfile refuses to answer it a second time — in the component, not by hiding a radio, because a form that hides a control has never stopped anybody who can post to /livewire/update. A record created before the question existed may still be given one, once. The panel is a fact rather than a form now, which is also what was odd about it, and the sentence about who has the right of withdrawal is gone. **Cancelling asks why.** A reason from a fixed list, required, with a note beside it that "Sonstiges" cannot go without — the one fact worth having about a departure, asked at the only moment the customer is looking at the question. It lands on the contract (`cancel_reason`, `cancel_reason_note`). And where the fourteen days are still running, the dialogue offers the WITHDRAWAL as a way out of itself rather than as one more reason inside it: withdrawing ends the service the same day and sends the whole amount back, cancelling keeps the term that was paid for, and somebody entitled to the first should not lose it by taking the second unasked. A business is never offered it — WithdrawalRight answers that, not the template. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:41:32 +02:00
nexxo	49d528dbea	Fix round: point at the real tab, hide the button nobody can press, prove the quiet page load ... Fixes four Important findings from the review of Task 12. Corrected nine check `tab` values at the source (BillingChecks was already correct; OnboardingChecks/ProvisioningChecks/DeliveryChecks all carried the pre-redesign 'integrations' value, which is not a member of Integrations::TABS): four onboarding checks now point at 'platform' or 'env' depending on where their field actually is, five provisioning/delivery checks point at 'services'. checkUrl()'s match-block resolver — praised as correct for the six checks that point at a genuinely different admin page — is unchanged; its `default` arm is now a pure safety net, not a route any check actually relies on. Wrapped the "Prüfen" button in @can('secrets.manage'): mount() admits hosts.manage OR secrets.manage, but runCheck() requires secrets.manage alone, so an Admin-role operator could see a button that 403s on press. Fixed a docblock on HEARTBEAT_KEYS that asserted a staleness threshold was kept in sync with OperationChecks::STALE_AFTER_MINUTES — that constant is a key/settings-name map with no threshold of its own, and no such synchronisation exists. Three new tests, each confirmed red against a deliberately reintroduced version of the bug it covers before being confirmed green: every check's tab value against where its field actually lives, the run-check button hidden from an operator who cannot press it, and Http::assertNothingSent() after a plain page load. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:26:10 +02:00
nexxo	e83b17ec37	Put every missing field on one page before a customer pays ... Admin\Readiness renders App\Support\Readiness::byGroup() end to end: state, label, breaks sentence and a fix link for every check, a button on the four that have to ask a real service (DnsTokenCheck, WireguardEndpointCheck, VmTemplateCheck, StripeCheck) and only ever run on demand, and one headline line — ready for the operator's current mode, or how many blocking items are still open. Wired into the nav and into Overview's own notice list beside the same gate as Admin\Integrations, since both halves it configures come back together on this page. Fixed two check keys the guard test caught for real: onboarding.ssh_key and delivery.inbound_password did not textually contain the vault key they check (ssh.private_key, inbound_mail.password), which is exactly the kind of silent gap this whole task exists to catch. Renamed to onboarding.ssh_private_key and delivery.inbound_mail_password, with the two existing test files that referenced the old keys updated to match. Also fixed the guard test's own assertion: Pest's toContain() is variadic, so a second string argument is a second required substring, not a failure message (the same trap tests/Feature/ModalHeightTest.php already documents about itself) — it failed on every entry, including ones already covered. Replaced with str_contains()+toBeTrue(), which keeps the check and the message both. Two pre-existing Overview tests assumed a bare install has nothing to report; it now correctly always starts with a readiness gap, so both were narrowed to what they actually test — no invented data, no invented incident. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:59:34 +02:00
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	fed4acf31c	Accept terms instead of a start date, and fix the sender no server accepts ... **The test mail was rejected: "553 5.7.1 Sender address rejected: not owned by user no-reply@…".** Every purpose mailbox here has its own SMTP account, and a mail server lets an account send only from the address it owns. Mail::to() hands back a pending mail bound to the DEFAULT mailer and sendNow() then ignores the mailer the mailable asked for, so a mail addressed support@ went out over the no-reply@ login. It sends through the mailable's own mailer now, and the cloud-ready preview — the one mailable with no mailbox at all — takes the provisioning mailbox like the real notification does. Writing the test for that found the same bug in production code: **InvoiceMail and OrderConfirmationMail set their From to billing@ and never named a mailer**, so both went out over mail.default's no-reply@ login. On this installation no customer had ever received an invoice mail or an order confirmation; they rendered perfectly, queued without complaint and were refused at the door. MailSenderOwnershipTest now scans for the mismatch: a mail that takes a mailbox From must use that mailbox's mailer. **The box on the order page accepts the terms now**, not an immediate start. It used to carry the whole FAGG §16 sentence, which read like a choice between "now" and "in fourteen days" — and there is no second option. The terms are what regulate the sale, so they had to exist: resources/views/legal/terms.blade.php replaces the placeholder with fourteen sections written from what this software actually does — the delivery, the capacity queue, the full refund on withdrawal, the cancellation at period end, the deletion deadlines. The company data comes from CompanyProfile, so the page and the invoices cannot drift. No availability figure and no liability cap has been invented. No order goes through without it: the button is unusable until the box is ticked and says why, and CheckoutController still refuses server-side — the browser half refuses nothing. The request field is `terms_accepted`; the Stripe metadata key stays `immediate_start`, because a session opened before a deploy is paid after it and the webhook would find nothing under a new name. **"Wird der Account nach fünf Tagen gelöscht?"** Only an unconfirmed one. That was the whole of what we said, so the answer looked like yes. The second rule now exists and is stated: PruneDormantAccounts removes a confirmed account after a year when it never had a package — no customer record at all, which is where every order, contract and seven-year invoice hangs. A fortnight's notice goes out first, once, and `dormant_warned_at` is what permits the deletion: an account whose warning never went out is never removed. Signing in resets the clock, measured off the device rows because users has no last_login_at. Both deadlines are said in the portal settings, on the verification page, and in the terms — each reading the number off the command that enforces it. Also: the wordmark scan matched any element whose text merely BEGINS with the company name, which a paragraph of terms does. It looks for the lockup form now (no whitespace after the tag), which is what it was always about. The seven checkout tests in the parallel session's files were posting the old field name and now post the new one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:22:35 +02:00
nexxo	96f171b3b3	Put the switch where it governs, and say when it is thrown ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:09:38 +02:00
nexxo	c354ad1463	Make mails readable on a phone, and let an operator look at one ... Three things the owner reported, and one sentence that promised something this product does not do. **The mails had a fixed width.** components/mail/layout.blade.php set width="600" and width:600px, so every phone showed a 600px canvas in a 390px window and one had to scroll sideways to read a sentence. Now the table is width="100%" with max-width:600px — fluid, with 600 as a ceiling rather than a floor. A mail cannot fix this with a media query (Outlook renders with Word and drops <style> blocks), which is why the whole file is inline attributes and why the shrinking has to be built in. Side padding went 40px -> 24px in the layout and in all nine mail views: 40 each side leaves 278px of a 390px screen to read in. **There was no way to look at a mail.** An invoice mail needs an invoice, a maintenance announcement needs a window, and "register an account to see whether the confirmation reads well" is not a workflow — which is how the fixed width survived for months. App\Services\Mail\MailPreviews builds all nine from sample data, every record with make() and never create(), so a preview leaves no invoice, order or window behind and draws no number from a series. Two ways to see one: in a tab as the document itself, or sent to the signed-in operator's own address. There is no recipient field — that would be a form for mailing strangers. sendNow(), not send(): every mailable here implements ShouldQueue, and send() defers to the queue for those, which would have put a failure in a worker's log while the button reported success to somebody waiting for the mail. The test caught that. **The booking page had no shell.** Order declared layouts.portal — the bare shell the sign-in pages use, no navigation and no padding — so the page sat flush against the top and bottom of the window with no way back to anything. layouts.portal-app, like every other portal page. **The consent box said something untrue.** Its refusal read "otherwise we can only build your cloud once the withdrawal period has ended", which describes a path that does not exist: nothing here delivers fourteen days later, and an unticked box simply means no order. Said plainly now, and said on the page before somebody runs into the refusal. Also: GrantedPlanPortalTest asserted assertDontSee('179'), which matches any id containing those digits — and ids climb through a suite run because a rolled-back transaction does not reset an auto-increment counter. It passed alone and failed in company. Asserts on '179,00' now, which is what a leaked price would actually look like. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 14:50:37 +02:00
nexxo	f49f1dca09	Say when no mail is being delivered at all ... "Ich versuche mich zu registrieren, erhalte aber keine Verify-Mail, auch nicht beim erneuten Senden." Traced rather than guessed, and the evidence is in storage/logs: the address appears three times, so the mails were built and handed to a transport that writes them to a file. MAIL_MAILER=log. MailboxTransport::resolution() short-circuits on it — NON_DELIVERING is ['log', 'array', null] — so every purpose mailer becomes the log transport however well the five mailboxes are configured, which is correct for a development machine and exactly what was happening here. The reason it deserves a notice is that the failure is silent in every direction an operator would look. Mail::queue() succeeds. No job fails. The queue empties. And the console's own mailbox test reports SUCCESS, because MailboxTester builds its own transport on purpose — a check that honoured MAIL_MAILER=log would report success while writing to a file. So every instrument on the page said fine. Now the front page says it, linked to the mail page, and the mail page says it above the mailboxes it makes decorative. All three swallowing values are named, not only 'log': array and an unset default do the same thing, and a notice that only knew about one would be silent in the two cases nobody thinks to check. Two existing tests asserted that a clean installation raises no notice, and went red — correctly, because phpunit.xml forces MAIL_MAILER=array so a suite cannot send mail. They pin a delivering mailer now: the warning is about the environment, those tests are about the estate. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 13:55:55 +02:00
nexxo	70fa136e22	Say on the front page that the site is switched off ... "Ich komme auf dem lokalen Dev-Server nicht auf www.dev." Diagnosed rather than guessed: Laravel answers 200 on that host, and the request never reaches it — site.public is false, so PublicSiteGate returns the placeholder with a 503 to every visitor who is not on the management VPN and not signed in as an operator. Which is precisely what a broken deployment looks like from outside, and the only place that said so was the switch itself, on another page. So the console says it now, on the page an operator opens when something looks wrong, and the notice links to the switch. The second half of the same report — being sent to app.… — is the missing SITE_HOST. Without it the marketing site is registered without a hostname: it answers on the PORTAL's host as well, and every route() it generates points at APP_URL, so a link on the site lands on the portal's domain. Also said, also with the host named. Only where the installation is host-separated at all, though. A fresh checkout binds nothing to a hostname by design — RestrictAdminHost: "upgrading must not lock anyone out of a system that was working" — and a warning there is furniture. My first version fired on every clean installation and two existing tests said so immediately; they were right. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 13:36:42 +02:00
nexxo	a84251260c	Read the mailbox password where it actually is, and let the console test it ... The inbox kept saying no mailbox was set up while the password sat right there on the settings page. isConfigured() read config('services.inbound_mail.password'), which is only ever the .env value: this project deliberately does not overlay stored secrets onto config at boot — SecretVault's own docblock says so, and HttpMonitoringClient reads its token at the point of use for exactly that reason. My docblock even asserted the opposite mechanism, which I never verified. It reads the vault now, and falls back to .env because SecretVault::get() already does. And a way to find out. "Verbindung prüfen" saves the form first — testing what is on screen while the server still holds the previous values would report on a mailbox nobody configured — then performs the same four verbs the real fetch performs: LOGIN, SELECT, SEARCH UNSEEN. A check that proves something easier than the actual job is worse than none. What it reports back is one of five fixed words, never the server's own prose: an IMAP error carries the command it failed on, and for LOGIN that command contains the password. Each word maps to a sentence an operator can act on — address and port, mailbox and password, the folder. The line saying when the mailbox was last reached is on both pages, and it is written by the SCHEDULED run as well as by the button. Otherwise "last checked" would mean "last time somebody pressed a button", which is the less interesting of the two: a mailbox that stopped answering at three in the morning is the one worth seeing, and nobody presses a button at three in the morning. It is also shown when the answer is "never" — an empty inbox and a mailbox that stopped answering look identical, and this line is the whole difference. A fetch against a mailbox that just refused the login now takes nothing in and records the refusal, rather than reporting "nothing new" — which was true and useless. Also: HostStepsTest asserted the literal clupilot.com for a host name. That was true until CLUPILOT_DNS_ZONE was set to clupilot.cloud on this installation, and then a correct configuration failed a test. The zone is pinned in the test now; what it is about is the shape of the name and which address it carries. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 13:12:29 +02:00
nexxo	889b401faf	Fix nine defects in the provisioning pipelines ... The capacity park could not survive its own first poll. ReserveResources polls every 120 s and declared a maxDuration of 60, and RunRunner measures a step's budget from a started_at it deliberately does not reset on a poll — so every re-entry was ruled timed out before the body ran, a timeout consumes an attempt, and five of them failed a paid order in about six minutes. The fourteen-day promise, the console's capacity queue and the "go and buy a server" workflow were unreachable code. maxDuration is now the whole park plus one poll interval, and a test drives a park through the runner rather than calling execute() directly, which is why this was invisible. Every guest occ call ran as root. `docker compose exec` defaults to root and the Nextcloud image's console.php exits 1 unless the caller owns config/config.php, so all five call sites were failing on every instance. There is now one builder, App\Support\NextcloudOcc, and a test refuses a second: nothing in app/ may spell the invocation out by hand. deploy/ update.sh had learned this for our own container and nobody carried it across. RunAcceptanceChecks was terminal on the first no. certReachable() answers false for a connect timeout as readily as for a missing certificate, so one bad second ended a finished, certified Nextcloud as a failed order with the instance released. The probes retry now and the run still fails for good with the probe's own reason once the budget is spent; the two facts a retry cannot change stay terminal. The in-flight guard asked whether anything was running, not whether it would do the work. App\Provisioning\WorkInFlight asks the second question, reading the step lists the runner executes: a domain proven during a restart is routed, and a storage pack booked during an address run is delivered instead of charged monthly and forgotten. The address pipeline ran its steps in the wrong order for the direction it exists for. Nextcloud before the router in `address` and `plan-change`, as in `customer`, because a run that got the certificate and then failed left the customer's own domain serving an untrusted-domain error under a valid certificate while the portal called it live. Safe in both directions; the reasoning is written above the pipeline. A stale guest_ip could never be corrected. ConfigureDnsAndTls compared the hostnames but never the backend, and nothing re-read the address after the build. It now records and compares `routed_backend`, and ConfigureNetwork joins the `restart` pipeline — a cold boot is what moves a DHCP lease — and asks for the address to be re-applied when the guest has actually moved. Also: HetznerDnsClient::upsertRecord read only the first page of a zone that pages at 100, so past a hundred records it created a second A record for the same name and the cloud was up about half the time; the console's retry left a live customer's order in `provisioning` for ever for any maintenance pipeline; and a revived run's first pass burned an attempt on a timeout that had already happened, because the clause written for it used `??=`. Seven test sites wrote config('provisioning.plans.*'), a key that has not existed since the catalogue moved into the database. Every write was a no-op, so each test proved something other than its name: the missing template, the two snapshot regressions and the grandfathered-price scenario are now actually constructed, ValidateOrder's reasons are asserted rather than only its type, and the end-to-end run checks that the quota step delivered something. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 01:34:55 +02:00
nexxo	518bc9aa41	Put the open tab in the address bar, including the first one ... Reported as "die Tabs fehlen in der Query beim Kunden". The binding was there and identical to the settings page — checked in the rendered snapshot, which is where Livewire's JS reads it from — but `except` hid the parameter while the DEFAULT tab was open. So arriving on a customer showed no ?tab= at all, and a link to the page could not say which tab it meant unless the tab happened not to be the first one. From the address bar that is indistinguishable from the feature not existing. No `except` now, on all three tabbed pages: the parameter is there from the first render. And `history: true`, so each tab is a step the back button can take rather than a silent replaceState — which also makes the change unmistakable while clicking. Asserted against the rendered page rather than the component, because the parameter is written client-side from the `url` memo in the snapshot: the memo IS the behaviour, and asserting the property would have passed throughout the bug. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 23:46:13 +02:00
nexxo	f00cbf18d3	Let an operator correct a customer's details ... The console could show them and not touch them, so a moved office or a new contact person meant impersonating the customer or editing the database by hand. Both are worse than a form. R20: a modal, opened from the Stammdaten tab, authorising again and reading the record itself rather than trusting anything the browser hydrated. Most of the work is in what saving must NOT quietly do. The customer type is never reset to "nobody asked". The field opens on "leave unchanged" precisely so that saving an address correction cannot undo it — that answer decides whether a withdrawal right exists, and losing it silently would be the expensive kind of quiet. A changed VAT number is unverified from the moment it is stored — the verification is bound to the value, so that happens by itself — but `vat_id_verified_value` is left alone: it is the record of what WAS checked, and clearing it would destroy the evidence rather than the claim. The address is also the sign-in address and the key inbound mail is matched by, so changing it moves the linked portal login in the same transaction and puts it back to unverified, which is what Laravel's own profile update does for the same reason: nobody has shown they can read the new address. No mail is sent from here — the portal asks for the confirmation at the next sign-in, and a mail an operator did not knowingly send is a surprise. Three addresses are refused: one belonging to an operator (R21 — no index spans the two tables, so it is checked), one belonging to another customer, and one belonging to somebody else's user row, which can outlive or predate a matching customer. Not offered here, each for its own reason: `status`, because suspending has consequences for access and a lifecycle switch hidden among address fields is one somebody flips by accident; `stripe_customer_id`, because a wrong one does not move a contract, it points our records at somebody else's payments; the brand fields, because the customer sets those for themselves and an operator overwriting a logo is not a correction. There is a test that fails if any of them appears — with the comments stripped first, since the class documents at length why they are absent and that documentation is not the offence. This repository has fallen into that trap three times. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 23:18:46 +02:00
nexxo	57c6912987	Say that a click landed, and make moving one actually move it ... "Man klickt und sieht nicht was passiert." Every action in this console is a round trip, and a round trip with no sign of itself reads as a click that missed — so the answer is in three places, from the general to the specific. A thin bar at the top of the window for any Livewire request, in app.js. Delayed by 140 ms, because a request that answers faster than that is perceived as immediate and a bar flashing on every keystroke of a .live field is worse than none. It creeps to 70 % and only completes on the answer: a bar that reaches the end while the answer is still on its way is a lie about the thing it exists to report. Released on failure as well — the request somebody must not be left waiting on is precisely the one that went wrong — and on wire:navigate, which is not a request hook at all and would otherwise leave the bar behind on a page that is gone. Per button: a pressed state on the way down, disabled while its own request is out, scoped with wire:target to that button's own call so a row does not grey itself out because a neighbour is moving. The edit button carries its own spinner, because opening the modal is a request made by the MODAL component — wire:loading on this page never sees it. It clears when the package announces the modal is up, and on a six second timer as well, so a request that never answers cannot leave a row spinning for ever. And the reordering was not only slow to look at, it was wrong. It added or subtracted a fixed amount: with the seeded values ten apart that usually landed right, and sometimes landed on a value another template already had — or on the floor along with three others. Equal sort values fall back to the name, so a click could reorder something else, or nothing, which is indistinguishable from a click that never registered. It swaps with the neighbour now: exactly one place, or nothing at the ends, both of which are what an operator expects to see. Where two shared a value the swap leaves them distinct, or the next click would do nothing again. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 23:06:30 +02:00
nexxo	f02e86769b	Charge the price the website shows, and hand a withdrawal back in full ... Stripe was charging the catalogue's NET figure while the document added the domestic rate on top: a customer quoted 214,80 paid 179,00 and was then invoiced for VAT nobody had collected. Under para 11(12) UStG that VAT is owed to the tax office whether or not it ever arrived, so every document issued created a liability against revenue that did not contain it. The Stripe Price now carries the GROSS figure. price_cents stays net - it is frozen onto every contract and PlanChange prorates against it, so redefining it would corrupt every pro-rata sum ever computed. Only the amount at the till moved, and it is formed by the one call TaxTreatment already answers for the price sheet and for the invoice, so displayed, charged and invoiced cannot drift apart. Stripe's automatic_tax is deliberately not used. TaxTreatment is the single tax authority here, and a second rate computed by Stripe would take 19 % from a German consumer while our document said 20 %. A Stripe Price cannot be edited, so a changed figure means a new Price and the old one archived - which stops it being SOLD and leaves every subscription already on it billing the old amount for ever. stripe:reprice-subscriptions is the second half, and a command of its own because it touches live money. A withdrawing consumer is refunded in full, as the owner decided. That is more generous than FAGG para 16 requires, and it makes the express-request consent the statute hinges on irrelevant - so the gate is gone rather than left looking load-bearing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 22:42:02 +02:00
nexxo	33566cd404	Show the customer, and write the answers once ... Two complaints, one cause: the customer page was a compose box with three lists under it. It showed nothing ABOUT the customer, and every answer was typed from scratch. The page is five tabs now. Stammdaten — contact, phone, since when, language, and the tax standing: consumer or business, with "nobody asked" saying so rather than passing for business, because that answer decides whether a withdrawal right exists at all. Paket — the contract's own FROZEN figures, the modules at the price they were booked at, and the machine: address, state, host, datacenter. Zahlungen — invoices with net, gross and their PDF, and the orders beside them, because an order is a purchase and an invoice is a document about one. Nachrichten — the portal requests in the customer's own words, the mail they sent, the mail we sent. Schreiben — last, because it is what you do after reading. The tab is in the query string, like Settings and Integrations: a reload, a bookmark and the back button all land where the operator was, and a link can point at the tab that matters. And templates, under Betrieb → E-Mail-Vorlagen. Most customer questions are the same five questions, and typing the answer again every time is how two customers get told two different things about one subject. A template is INSERTED into the compose field with the customer's own details filled in — never sent as it stands, because the last two sentences always belong to the person asking. What goes out is what the operator saw and edited. Three decisions worth naming. {{contact}} takes the contact person where one is on record and the company name otherwise, because "Guten Tag Beispiel GmbH" is the line that gives away a mail written by a database. {{amount}} is the gross figure — what the price sheet quoted them and what their bank statement says. And a typo comes out as {{kunde}}, standing there in the field where the operator sees it, rather than as an empty string that produces "Guten Tag ,". A placeholder with no value for this customer stays empty; nothing is invented. Placeholders are named in English because they are identifiers, not prose: a template has to survive somebody switching the console's language. The list the page documents is the renderer's own, so a token added in one place appears in the other without being written down twice. Blade's echo tag ends at the first }} it finds, which turned a literal placeholder in the documentation into compiled nonsense. Assembled in PHP now, and caught by the test that renders the page rather than by somebody opening it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 22:37:30 +02:00
nexxo	e376b571be	Read the support mailbox into the console ... No, not an API token: mailcow's API administers domains and mailboxes — it does not read mail. Reading a mailbox is IMAP whoever runs the server, so that is what this is. Host, user and folder are console settings; the password is a vault entry, like every other credential that opens something. IMAP by hand rather than a dependency. Four verbs are needed — LOGIN, SELECT, SEARCH UNSEEN, FETCH — and the parsing that follows is the real work either way. It is bounded by what the console shows: a sender, a subject, the words a person wrote, and the NAMES of anything attached. Real mail from real people arrives encoded, so it handles RFC 2047 subjects (every German subject with an umlaut in it), quoted-printable and base64 bodies, Windows charsets, and multipart — text wins over HTML, because a console is not a mail client and the words are in the text part. A message it cannot make sense of is skipped and logged, never guessed at: a garbled question in front of an operator is worse than one they go and read in the mailbox, where it still is. ATTACHMENTS ARE NOT STORED. Only their names and sizes, so an operator knows something was attached and can go and look if it matters. Keeping whatever a stranger chooses to send would make this application a malware store with a web interface in front of it. Whose a mail is, is decided by the sender's ADDRESS and by nothing else — not by a name in the subject, not by anything in the body. A mail is easy to write and this decision attaches a stranger's words to a real customer's file; there is a test that forges the name and the subject and still gets nothing. An address nobody recognises stays unassigned, shown FIRST and never hidden: that is a new enquiry, or a customer writing from their private account, and it is the mail that must not be missed. An operator can place it by hand from the same row. Nothing is deleted on the mail server, ever. Messages are flagged seen once the row is safely written — and only then, because flagging first and failing after would lose the message with no second copy anywhere. Filing one away is this console's own state; the mailbox is untouched. Two fixes on the way past: the customer page printed "customers.status.active" and "support.status.open" — a lang key with no file behind it renders as itself and Laravel says nothing — and the same page is now covered by a test proving each list is scoped to the customer in the URL, which was reported as "unterhalb steht immer das selbe". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 21:41:29 +02:00
nexxo	6d7c2bdf35	Ask whether they are a consumer, and let one change their mind ... Three things the product owed its customers and did not have. **Who is on the other side.** There was no consumer/business flag anywhere, and `vat_id` was standing in for one — which it cannot: a business without a VAT number is an ordinary small business, and a consumer with one does not exist. It is asked at sign-up now, correctable in the portal, and NULL where nobody has been asked. Unknown is read as CONSUMER everywhere it decides a right, because that mistake costs us a refund while the other one takes a statutory right away from somebody who has it. Reverse charge asks the recorded type instead of the number: an explicit consumer is charged the domestic rate whatever `vat_id` says — previously they were not, and anyone could zero their own VAT by getting a number verified. An unrecorded type still falls back to the verified number, so no contract that is already running changes rate. **The fourteen-day right of withdrawal** (FAGG, §312g BGB), for consumers only, at every door: the window is stamped on the contract when it is concluded, the customer exercises it from the portal, an operator records one that arrived by telephone or post, and both go through one action that refuses a business customer on the server rather than by hiding a card. The money follows the paperwork rather than being computed beside it. The invoice is cancelled by a Storno with its own gapless number — nothing is ever edited or deleted — a new invoice states the pro-rata value of the service actually delivered (FAGG §16, by days over the term paid for), and the refund is exactly the difference between the two documents. Where the consumer never expressly asked for the service to begin at once, they owe nothing and the whole amount goes back. `StripeClient::refund()` is new, keyed so a retry cannot send the money twice. The service ends through EndInstanceService and the `cancellation_scheduled` machinery that was already there. **The cancel button for modules.** BookAddon::cancelAtPeriodEnd() had no caller in the interface at all, so a customer could book a recurring charge in two clicks and had no way to stop it. It is on the module card now, with the date it runs until and a way back while the cancellation is still pending — and putting a module back settles nothing, because the term it was cancelled for was paid for in advance. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 21:06:06 +02:00
nexxo	0e25fe88d4	Keep a register of what was sent, and answer the customer from here ... Three complaints, one shape: the console knew things and could not act on them, so the work happened somewhere else and left no trace. The header said "4 Hinweis(e)" and led nowhere. Whoever read it had to know that the list was a card further down the same page, and then go looking for the host or the failed run by hand. The count is a link now, every notice carries the page that shows the thing it is about, and the plural is a word rather than a bracket. Nothing recorded what this installation had sent. "Hat der Kunde die Zugangsdaten je bekommen, und wann?" was answered on the mail server — a different machine, a different program, and nothing an operator can put in front of somebody who says nothing ever arrived. Every mail now writes a row: when, to whom, which mailable, and the customer it belongs to. Written from MessageSent, so a row means the transport accepted it; that is the strongest thing an application can honestly claim, and a column called "delivered" would be pretending otherwise. Verification and reset mails are left out on purpose — they go to unconfirmed addresses and anybody who can type into a form can send them, so recording them would hand the register to whoever wants to fill it. And the customer list was the end of the road. There is a page behind it now: what they bought, what they asked in their own words, what we sent them, and a box to write the next message. It goes out from the support mailbox and is recorded on the way — with its body, because an operator typed it and "what exactly did I write to them in March" is a question the mail server's log cannot answer either. Answering a request from here closes it, which is the reason to answer from here at all: answering from a mail client leaves it open for ever, because nothing tells it otherwise. Found on the way, by a test that sent a real mail rather than asserting it was queued: resources/views/mail/reset-password.blade.php was missing its closing </x-mail.layout>. The component's contents were never terminated, the layout's own @if ran off the end of the file, and the mail raised a Blade syntax error instead of rendering. Password reset has therefore never delivered a link since it was built. Closed, plus a test that renders it and one that counts opening against closing tags across every mail view. Reading INCOMING mail in the console is not in this: it needs the mailbox polled over IMAP, which is a credential and a dependency. Requests filed through the portal appear here in full; a customer who writes by mail instead still has to be read in the mail client. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 21:02:36 +02:00
nexxo	6b8412f0c3	Write an invoice for work that came off no price list ... Not everything we are paid for is a package. Somebody asks whether their data can be moved into Nextcloud; we look at it, we say what it costs, we do it. That is a real invoice with no order and no contract behind it, and the only way to produce one was to write it somewhere else — which puts it outside the series. A numbered series with a document missing from it is worth nothing at an audit. So it goes through the same door as every other invoice: IssueInvoice::forService() draws from the same series and therefore the same consecutive number, applies the same TaxTreatment (a verified business in another member state gets its reverse charge and the note that makes a zero-rated document lawful), freezes the same immutable snapshot and dispatches the same archive jobs. The page under Rechnungen writes what the operator typed and nothing else. Amounts are in euro because it is a form — 12,95 becomes 1295 by round(), not by a cast that would make it 1294 — and quantities go to a thousandth because hours are billed in quarters. The total beside the lines is the same InvoiceMath the document uses; a preview doing its own arithmetic would be a second answer, and the first one anybody notices differs is on a document that cannot be changed. There is no draft: a "save as draft" that draws a number is an issued invoice with a friendlier name. The website's buy buttons go to the sign-in now, not to /order. Booking belongs in the panel, where the account exists and its address has been confirmed — which matters because that address is where the finished cloud's credentials are sent. Sending an anonymous visitor at a page behind auth worked, but only via a middleware bounce off a page they never asked for. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 20:12:26 +02:00
nexxo	f85f57152e	Let the customer buy it themselves, and tab the integrations page ... Every path on the site ended in "anfragen": a mailto: link and a promise to answer the same working day. That is an afternoon of somebody's time per customer, for a product whose whole point is that the machine does the work — and it scales exactly as far as one inbox does. Now: sign in, pick a package, pay, and provisioning starts by itself. The pieces were already there — Stripe holds a Price per plan version (the catalogue sync writes the ids), the webhook opens the contract, the pipeline builds the VM — and what was missing was the checkout session between them. CheckoutController opens one and gets out of the way; the purchase becomes real on the webhook, which stays the only place allowed to believe a payment happened. The success URL is a redirect target and therefore a URL anybody can type, so it says "we are building it", not "you have paid". Nothing in the request may decide the price. The plan key arrives from a form and everything else is re-derived from the catalogue, including the plan VERSION, so a version published while the customer types their card number cannot change what they were quoted. Two cases that are not errors: no capacity is a parked order (already built), and an existing customer is sent to the plan change rather than sold a second, empty cloud that bills twice. The site says what it can keep. "danach wissen Sie … wie Ihre Daten sicher umziehen" was a promise made before seeing the thing it is about: we do not know where a visitor's data is, what shape it is in, or whether it can be moved at all. Migration is named as its own question, looked at first and quoted afterwards. The integrations page gets the settings page's treatment for the same reason: it was one narrow column of six cards, so an operator connecting DNS scrolled past Stripe to reach it and the raw .env editor sat at the bottom of everything. Three tabs by what a section is FOR — services we buy from outside, our own machines, the file underneath — the same axis the page was rebuilt around when it stopped being split by storage mechanism. The tab is in the query string; unlocking survives a switch, because a confirmed password is a session fact and not a property of a tab. The .env tab is Owner-only, like the editor it holds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 19:42:28 +02:00
nexxo	7265799881	Quote what a person pays, and tab the settings page ... Prices. The sheet quoted net, which is the wrong number for one of its two readers: a private customer has no way to add 20 % in their head and no business being surprised by it at checkout. The gross figure is now the big one, with the net underneath for a company's books, and the same rule applies to the module prices further down — a sheet that quotes the package with VAT and the module without it is a sheet whose numbers cannot be added up. The rate is the one on the Finance page, the same one an invoice uses; a percentage written into the template would be the second source that makes the two disagree. "zzgl. einmaliger Einrichtung" had run for months without ever naming a figure, which leaves a visitor knowing only that there is one. It is a field on the Finance page now and prints with the price. Zero removes the sentence — and the comparison card that listed the fee as the honest downside of the offer — rather than admitting to a cost that is not charged. Layout. Four packages in 1120px left each card 202px of text, which is what broke "Bereitstellung in 2-3 Werktagen" over two lines and made the cards look pressed against each other. The pricing section is wider than the rest of the page (only it: the reading columns elsewhere are narrow on purpose, a price sheet is four columns that must be comparable at a glance), the gap between cards is larger, and the delivery line is short enough to fit with whitespace-nowrap to keep it that way. Navigation. VPN moves from Betrieb to System: the tunnel is not a task of the day, it is how the console reaches the estate at all. Settings. The page had grown to three headed sections in one column with the operator's own password somewhere in the middle. It is tabbed now, and two-factor enrolment is one of the tabs instead of a menu entry of its own — it is a setting, and it was the one thing an operator had to leave this page to change about their own access. Same component, no second copy of the enrolment logic; it still answers at its own route because RequireOperatorTwoFactor sends an operator there who may not open anything else yet, this page included. The open tab lives in the query string, so a reload, a bookmark and the back button all land where the operator was. That matters here more than elsewhere: the installation tab refreshes itself while an update runs, and a tab kept only in the component would drop them back to the first one mid-deployment. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 19:18:10 +02:00
nexxo	5b63fdb86c	Deliver the storage a customer actually buys ... A booked storage pack was a row in `subscription_addons` and nothing else: priced, frozen, charged every month, and delivered nowhere. Nextcloud's quota came from `instances.quota_gb`, which is the package alone; the disk was sized for the package alone; and on the one occasion a disk did grow — a plan upgrade — the guest never saw it, because nothing stretched the partition or the filesystem over the new space. One authority for the allowance. StorageAllowance adds the package and the booked packs, and everything that needs the figure asks it: the quota step, the downgrade check, the portal, the console, the repair command. It is DERIVED rather than stored — a column would have to be rewritten by booking, cancelling, granting, a grant expiring and a plan change, and the day one of those paths forgot it would be silently wrong in whichever direction costs somebody money. `quota_applied_gb` keeps its own meaning: what the guest was last actually told, which is how a machine with the allowance enforced is told from one where the figure has only ever been a row in our database. Buying it delivers it. BookAddon asks ApplyStorageAllowance for a run on booking AND on cancellation; the new `storage` pipeline grows the virtual disk to the allowance plus the package's own overhead (read off the package — 20/40/50/100 GB on the four catalogue packages — never a ratio invented here), then GrowGuestFilesystem makes the guest see it, then the quota is applied. No cold boot is involved: the data disk is scsi0 and Proxmox's resize on a running guest is a qemu block_resize, so the capacity reaches the guest while it runs. The new step rescans, growparts and grows the filesystem with the tool its type actually needs — ext2/3/4, xfs, btrfs — and fails loudly on one it does not know rather than handing it to resize2fs and hoping. Idempotent end to end: NOCHANGE from growpart is not a failure, and every tool here exits 0 when there is nothing left to grow. The same step now runs in the plan-change pipeline, where an upgrade used to stop one step short of the customer. A downgrade blocked by data gets a way out. The block stays — it is correct — but the check now measures against the target package PLUS the packs the customer already owns, and reports the numbers behind the refusal: what is stored, what would be allowed, how much has to go, and how many packs would cover it instead. The portal offers both routes: book exactly those packs (confirmed in a modal, R23), or delete data and have the fill level measured on demand rather than waiting for the nightly sampler. That reading is taken by DiskUsageProbe, which CollectInstanceTraffic now uses too, so there is one notion of "how full is it" and not two. A plan change keeps booked packs. They were paid for separately and have nothing to do with which package the customer is on; the new package's disk and quota are sized with them included. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 19:13:10 +02:00
nexxo	ec8675861e	Take the order, park it, and say when it will be delivered ... A paid order that no host has room for used to FAIL at the reservation step. The customer has paid by then, so that turned a sale into an incident and left somebody holding money against nothing. The estate is finite and booked thick, so "no host has room right now" is an ordinary Tuesday — it means a machine has to be bought, which takes days. So the order waits instead. poll(), not retry(): the wait is measured in days and must not eat the run's attempt budget. It only fails after PARK_DAYS (14) — long enough to buy, rack and onboard a server over a weekend, short enough that a forgotten order surfaces instead of waiting for ever. Then say so, in the same words on both sides of the payment: - The price sheet marks each package "wird sofort ausgeliefert" or "Bereitstellung in 2-3 Werktagen", read from free capacity rather than written into the page. - The customer's own overview says their cloud is being prepared while it is parked, instead of a stepper standing still for two days under "wird eingerichtet" — which reads as broken. - The console front page shows the same per-package answer, so an operator can see what visitors are being promised. And a capacity page for the decision that follows: who is waiting, what the roomiest host still has, what the queue needs ("3x Start, 1x Business" - the LARGEST parked package sets the minimum machine, because an instance lives on one host), and what such a machine costs today from the provider's live list. It orders nothing: buying a server is a contract, and a bug in a capacity calculation must not sign one. The operator can also say where each parked order goes. A pin is honoured or it waits — never quietly redirected — because placing it elsewhere answers a different question than the one they answered, and they would find out from the finished instance. Two things this shook out: - `current_step` is an INDEX into the pipeline, not the step's key, and it is cast to integer. `where('current_step', 'reserve_resources')` reads as correct and matches step 0 of EVERY pipeline instead. Both lookups go through HostCapacity::parkedRuns() now, which resolves the index and filters by pipeline. - The auction feed sends `hdd_hr` as a list, not a string. Casting it printed "Array" into the console and raised a warning that took the page down with it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 18:50:46 +02:00
nexxo	d76de5ada3	Restart a machine, enforce the quota that was sold, end a route that ended ... Three places where the product said one thing and did another. **Nothing could restart a virtual machine.** ProxmoxClient had startVm and no way to stop anything, so `restart_required_since` — set by every plan change that grows a running guest — could only ever be cleared by a resize step that happened to find the machine stopped, which nothing in the product could arrange. A paid upgrade's cores and RAM could stay unreached for the life of the contract, and the cloud page's "Neu starten" was a toast. There is now a `restart` pipeline: shutdown, start, wait for the agent, confirm. A shutdown and a start rather than a reboot, because only a cold boot makes qemu read the VM definition again — a reset would take the machine round and bring it back exactly as small as it was. The shutdown is a REQUEST, bounded at ten minutes, and there is no escalation: ProxmoxClient deliberately does not expose Proxmox's forceStop, because the guest is a Nextcloud and cutting power to a database mid-write to apply a CPU change trades an inconvenience for a restore from backup. A guest that ignores ACPI for ten minutes fails the run instead, and a person decides what happens to it. `restart_required_since` is cleared by the last step, from what the RUNNING guest reports (`cpus`/`maxmem`) — not by the button, and not by the run merely finishing. A machine that comes back smaller than it was sold fails the run. Started by App\Actions\RestartInstance, which re-checks authorisation itself rather than trusting a hidden button: an operator holding the new `instances.restart` may restart anything, a portal user their own machine and nothing else. Refused while another run is in flight against the same order. Confirmed in a modal on both sides (R23), addressed by uuid (R11). **Existing instances had no storage quota.** ApplyStorageQuota reaches new and changed machines; everything built before it kept the whole disk whatever it had paid for, and nothing recorded which was which. `instances.quota_applied_gb` is now what the guest was actually told, written by the step only after the occ call succeeds — so "sold" and "enforced" are separate facts and can be compared. `clupilot:apply-quotas` sweeps the estate: one `quota` run per instance through the same step the pipelines use, skipping what it should and saying why, a no-op once an allowance is enforced, and inert under --dry-run. Deliberately NOT scheduled — a nightly sweep would quietly cover for the pipeline step the day it stopped working, which is how the original hole survived this long. **A Traefik router was never torn down.** TraefikWriter::remove() had no caller anywhere. What was missing was the moment: ConfirmCancelPackage wrote a date into `service_ends_at` and nothing ever went back to it, so every route this platform ever wrote was written for good — pointing at a guest address the host is free to reassign. `clupilot:end-due-services` (hourly) keeps that appointment through App\Actions\EndInstanceService. "Ended" means cancellation_scheduled AND `service_ends_at` passed, never the day a cancellation is scheduled: that customer has paid to the end of the term and is working in it. The DNS record goes with the route — it is in our zone, pointing at a host that serves other people, which is the shape of every subdomain takeover there has ever been. The customer's own domain is in their zone and is not ours to touch; the virtual machine is left alone, because the cancellation flow promises a data export first and destroying disks is not this change's decision. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 18:28:28 +02:00
nexxo	98d884727a	Warn that a package cannot be placed, before somebody pays for it ... The platform books thick: a package reserves its whole disk_gb — the sold quota plus the machine's own overhead — on ONE host at placement. That is the right choice for a small operator, because nothing can quietly overfill. It has one consequence nobody was being told about: the catalogue goes on offering a package no host has room for, and the first anyone hears of it is a PAID order failing at the reservation step. On the machine this was found on the numbers are stark. 2 x 512 GB NVMe in a mirror is about 400 GB usable; Start reserves 120, Team 540, Business 1050, Enterprise 2100. Three of the four packages on sale cannot be placed at all, and the fourth fits three times. So the console says so now, per package, with the shortfall — "Team needs 540 GB, the roomiest host has 260" — because "buy a server" is not the decision. "Buy a server big enough for what I am selling" is. Two things it deliberately does not do. It does not warn on an installation with no host at all: that is a machine nobody has onboarded yet, it has its own notice, and without the guard a fresh console greeted its operator with one warning per package before they had done anything. And it does not take the overview down when the catalogue cannot be read — a capacity warning does not get to break the page somebody opens when something is already wrong. The largest FREE HOST, never the sum: an instance goes on one machine, so two hosts with 300 GB each cannot take a 540 GB package between them. And when placement does fail, the log now names the shortfall instead of only 'no_capacity'. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 18:20:51 +02:00
nexxo	8f2252e81b	Book a downgrade for a date that cannot move, and sell a module once ... Two ways of charging a customer for something they did not get. A downgrade was due when `subscriptions.current_period_end` said so, and Stripe pushes that column forward on every renewal. So a downgrade booked in March was deferred to the end of April by April's renewal, and to the end of May by May's — each time by a whole term, and each time the customer was billed again for the package they had asked to leave. The due date was being re-derived from a moving target on every scheduler tick. It is decided once now, at the moment the customer decides, and stamped onto the contract: `pending_plan` and `pending_effective_at`, the two columns that have been in the schema since the first migration and were written by nothing at all. The shop stamps them, PlanChange reads them instead of the period end when a move is already booked, and clupilot:apply-due-plan-changes finds contracts by the stamped date rather than orders by a date it recomputes. The order stays what it always was — the customer's own record of the request, what the cart shows them and what they remove to change their mind — so it is still consumed with the change, and removing it unbooks the change. What it no longer does is decide when. A second downgrade replaces the first rather than queueing behind it; an upgrade clears one, or it would come due months later and undo the bigger package; a contract cancelled before the date takes the booking with it; and a customer with no contract can no longer place a downgrade at all, which was accepted before and could never be carried out. A booked change is now visible where the contract is read: on the plan card in the portal, because the cart entry disappears when it is paid for and the booking does not, and on the customer row in the console, because that is where an operator answers "what is this customer on". The second defect is the same money in one step: BookAddon guarded duplicates per ORDER — the unique index on (order_id, addon_key) — so two orders for the same module on one contract both went through. A stale tab or a double click bought priority support twice. But storage is deliberately sold in packs, and AddonCatalogue sums the quantities for exactly that reason, so "refuse the second" is only right for some of them. Which is which is declared beside each price in config/provisioning.php (`sold_as`), because it is a commercial decision about each module and not something to infer from a key: storage is a quantity; off-site backups are on or off, support is prioritised or it is not, Collabora Pro is one licence, and a machine answers to one own domain. An undeclared module counts as an entitlement — the cheaper of the two mistakes — and a test refuses to let one ship undeclared. Enforced in the action, where the portal, the console's grant screen and a webhook all pass, with the sentence the customer is shown rather than a developer's. A retried webhook for the SAME order still gets its one booking back; that is one purchase arriving twice, not two purchases. The portal stops offering what would be refused — booked, or already waiting in the cart — and goes on offering the pack. What is missing is on the Stripe side and is not invented here: nothing moves the subscription's item onto the new Price, so the renewal after a plan change still bills the old plan at Stripe. StripeClient only creates and archives catalogue objects, and swapping a price also needs the subscription ITEM id, which nothing stores. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 17:51:37 +02:00
nexxo	34874adec3	Apply a bought plan change instead of only pricing it ... PlanChange could say what a move would cost and whether it was allowed, and that was all it could do. Billing::purchase() wrote an upgrade order and nothing ever consumed it: same snapshot, same machine, same quota. A customer could pay for a bigger package and receive nothing. ApplyPlanChange is now the single place a change lands — it moves the contract onto the target's current version, writes one register row, settles the custom domain, and starts a run that resizes the machine. Applying the same order twice is a no-op, enforced by a unique event key rather than by a check two callers could both pass. Two things a plan change must not do, and now does not. A disk is never shrunk — Proxmox cannot, so the QUOTA shrinks instead, which is what was sold anyway. And a live machine is never rebooted as a side effect: cores and RAM are written, and where they need a restart the instance says so where an operator and the customer can both see it. The storage allowance also joins the build pipeline. ApplyStorageQuota was written for plan changes and ran only there, so a brand-new customer still got no quota at all — quota_gb reached the instance row and stopped, and every package delivered the whole disk. The test guarding that pipeline only counted its steps, which is how a list missing the one step that makes a package's storage real stayed green for its whole life. It now names the step. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 17:18:55 +02:00
nexxo	6ef9b510ce	Merge branch 'feat/plan-reopen' ... # Conflicts: # app/Http/Controllers/LandingController.php	2026-07-29 16:20:07 +02:00
nexxo	6c92aa5dd7	Let an incident be deleted, and start measuring whether the hosts answer ... Three things, all from trying to actually use the incident page. ── Where the later entries go ─────────────────────────────────────────────── The form only ever creates the first one, and nothing said so — so it looked as though the stage had to be chosen up front and there was only a dropdown for the impact. The field now says what it becomes ("wird untersucht") and where the rest are added: on the incident itself, once it exists. ── Deleting ──────────────────────────────────────────────────────────────── Asked for in order to test the thing at all, and right. A whole incident can now be removed, with its entries, behind a confirmation in the product's own dialog (R23). Deliberately not the same as editing an entry, which there is still no way to do: an update is a statement made at a time, and rewriting one afterwards is what the record exists to prevent. Removing the whole incident is a different act — it is how a test entry, or one published against the wrong service, is taken back, and it leaves nothing half-standing behind. A test holds that distinction so the delete button does not quietly become an exception to it. ── The hosts, which nothing was watching ──────────────────────────────────── `hosts.last_seen_at` drove the health dot in the console and was written exactly once, at onboarding — RegisterCapacity stamped it and that was the only write in the codebase. So every host read "offline" thirty minutes after it was added, permanently, and the dot meant nothing. It is also why host reachability could not appear on the status page: it was never being measured. PingHosts asks every host's API the cheapest question it answers, once a minute, and stamps the timestamp on success. Failure writes nothing on purpose: absence IS the signal, and a second column counting failures would be a second version of the same fact. The status page has a fifth component for it. Counts only — never a host name, never an address; the page is world-readable and the estate is not public information. A host between five and thirty minutes silent reads as degraded, not as healthy: "stale" is one of three answers healthState() gives and it is not the good one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 15:16:48 +02:00
nexxo	0e3c50d9a1	Update on a schedule if the owner wants one, and say where incidents go ... ── Where the status page gets its data ────────────────────────────────────── Asked in as many words, and fairly: the page for maintaining incidents exists (console → Betrieb → Störungen) and nothing anywhere said so. The page now carries the answer at the top — what is written there appears publicly at once, the four components measure themselves, and there is a link straight to the live status page. ── Automatic updates, inside a window, switchable ─────────────────────────── Tick it and name the days and hours; leave it alone and nothing changes. The button stays either way: manual is always possible, at any hour. It leaves exactly the same request the button leaves — same file, same agent, same run. A second path into a deployment would be a second set of rules to keep in step with the first, and the automation must not be able to do what an operator is prevented from doing by hand: it checks the same three things the button is disabled by (agent alive, something released, nothing running). Nothing guards against having already updated by hand, and nothing needs to: an installation that is current has nothing available, so pressing the button at four leaves the five o'clock window with nothing to do. That was the owner's own question and it answers itself. Defaults are Tuesday to Thursday, 05:00–06:00. Not Monday — the week starts and every fault costs double. Not Friday — nobody wants to repair a deployment on a Friday afternoon. Not three in the morning: if it goes wrong, the person who has to fix it is asleep. A window whose end is before its start wraps past midnight, because 23:00 to 02:00 is a reasonable thing to ask for and reading it as an empty range would silently mean "never". Switched on with no weekday selected is refused rather than corrected — it is a configuration that reads as working and does nothing. The clock is the wall clock (R19): an operator who writes 05:00 means five in the morning where they live, and a window that drifts by an hour twice a year is a window nobody trusts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 15:01:54 +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	ea643b5e73	Prove a custom domain before serving it, and keep proving it ... Two things. ── The update screen, still opening twice ─────────────────────────────────── Reported again on 1.3.9, and the cause was not the one fixed in 1.3.8. The agent consumes the request file BEFORE it resolves the release — deliberately, because update.sh may kill the shell and a request left in place would loop — and writes `state: running` only once it has decided to go ahead. In between, the request is gone and the status does not say running yet, so the endpoint honestly answers "nothing is running". The watcher read that as "the run has finished" and reloaded the page: overlay on the click, gone a poll later, 503 after it. The overlay now closes only once the server has BOTH confirmed a run and then stopped reporting it. Before the confirmation, silence means the agent has not got there yet. Bounded at twenty polls so a request the agent refuses does not leave the console covered forever. ── Custom domains, proven and re-proven ───────────────────────────────────── `custom_domain` was a free-text field and everything downstream believed it: the proxy served it, the certificate was issued for it, Nextcloud trusted it. Anyone who pointed any hostname at the platform got somebody else's files under their own name. The proof is a TXT record at _clupilot-challenge.<domain> holding a token only this instance has. Nothing is served until it has been read. Every reader now goes through Instance::address(), which is the one place the decision is made — `custom_domain ?: subdomain` was the hole, written out four times. It is re-read every night at 03:40, because a token checked once can be taken straight back out and a domain that later lapses keeps resolving here. Three consecutive misses before a live domain is withdrawn: one failed lookup is a nameserver having a bad minute, and withdrawing takes a working Nextcloud off its own address. The domain and its token stay on the row so the customer can put the record back rather than start over. Changing the domain mints a NEW token. Reusing it would let somebody who once verified example.com claim any other domain later without touching its DNS — the old record is still sitting there and only the value is compared. The domain is changeable at any time, and removable. Fixing it once set was considered and rejected: adding or moving an address is a proxy entry, a certificate and one line in trusted_domains. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 14:47:51 +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	b843c10ec3	Give the update screen the product's colours, and only one window ... Two complaints, both correct, both mine. Dark blue. The panel carried a `prefers-color-scheme: dark` block — the only one in a product that has no dark mode. On a phone set to dark the update screen, and nothing else, turned dark blue. A dark mode for one page is not a dark mode; it is one page that does not match. It is gone. And even in daylight the panel was not this product's colours: it used Tailwind's slate ramp (#0f172a, #64748b, #e2e8f0), which is blue-tinted, against neutrals that are warm. Every value is now a copy of a token from portal-tokens.css, with the comment saying so, because this file cannot import them — it renders when the asset build may not exist. The small window then the big one. The settings card grew its own little "läuft gerade" block the instant a run started; up to three seconds later the full-page overlay covered it and said the same thing in a different size. The card no longer says it at all, and the overlay now opens on the button's own click — requestUpdate dispatches an event, but only once a run is actually pending, so a refused second press does not black out the console. Two more things found while looking: The panel had `min-height: 100%`, which resolves against the parent's height. On the 503 page the parent is <body>, whose height is auto — so it computed to zero, the panel was only as tall as its text, and the bottom two thirds of the screen stayed the browser's default white. Viewport units now, dvh so a phone's collapsing address bar leaves no strip either. And the mark was a plain orange tile again, the same empty-square that was just fixed on the placeholder. The real logo is inlined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 14:11:01 +02:00
nexxo	b85df4c141	Rebuild the status page as a status page ... Asked for after looking at how real ones are built. The shape they all share is a convention, and a convention is what lets somebody find the answer without being taught the page: banner, components each with ninety days of uptime, then the written record underneath. This page had only the banner — the version that is of no use the morning after, because "Alle Dienste in Betrieb" is true and says nothing to somebody who was locked out the evening before. Three things are new. The ninety-day bar. It cannot be reconstructed after the fact: the monitoring table holds the last verdict per instance, not a history. So a sampler (clupilot:sample-status, every five minutes beside the monitoring sync) writes counts into one row per component per day, and the page divides them. A day with no row is drawn as a gap and says "nicht aufgezeichnet" — never green. Degraded samples count as reachable in the percentage but still colour the day: folding them into downtime reports a slow morning as an outage, ignoring them loses the only trace of it. The incident record. An operator reports a disruption in the console, posts updates as it develops, and the entry that says "behoben" is the same action that closes it — two separate steps is how a page ends up with a resolved note under an incident that still reports as ongoing. There is deliberately no way to edit an update: it is a statement made at a time, corrections are a further entry. An open incident may make a component look worse than the probes found it, never better. Scheduled maintenance, from the windows the console already keeps rather than a second list somebody has to remember to fill in. The measurement moved out of the controller into ServiceHealth, shared with the sampler, so the banner and the bars cannot disagree about what "healthy" means. The page now uses the shared design system and the site's header and footer. Its self-contained stylesheet was there to survive a broken asset build; it does not survive one — if the stylesheet cannot be served the application serving this page is already failing, and mid-deployment every route answers with the maintenance page. What the exemption bought was a third design nobody maintained. Found while building: durationMinutes had its operands the wrong way round, and diffInMinutes is signed, so the public page printed "Dauer -86 Minuten". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 12:45:18 +02:00
nexxo	3b85e8f1d1	Grant a package or module from the customer's row in the console ... GrantPlan is a modal (R20), opened from a "Schenken" button on the customer's own row in Admin\Customers, gated by customers.grant_plan rather than merely hidden. It offers a whole package (plan, term, datacenter, an optional quota bonus baked into the frozen snapshot) or a module on an existing contract, either free or at a discount the operator sets against today's catalogue price. Existing grants show on the same modal — who gave what, when, and until when — with a warning once a dated grant is nearing its end; nothing lapses on its own, exactly as decided. The customers list also badges a granted plan in the Paket column.	2026-07-29 12:42:21 +02:00
nexxo	c71b2c362b	Skip the invoice for a full gift, keep it out of revenue, hide its price ... IssueInvoice now rejects free-grant orders before it will consume an invoice number for them — a full gift produces no invoice at all, while a discounted grant still charges something and is invoiced exactly like an ordinary sale. Keyed on the linked subscription/add-on's own provenance, not on the amount being zero, so a genuinely fully-discounted Stripe checkout is unaffected. Revenue excludes granted contracts from MRR/ARR/ARPU and the contracts count — a gift at 0 must not drag the average down — and shows their number as its own KPI instead of folding it in, since the owner measures himself on it. The portal (Cloud, Billing) shows a granted package or module without a price at all: not "free", not struck through, just the service, so a later conversion to paid does not read as a negotiation.	2026-07-29 12:41:32 +02:00
nexxo	15b536f393	Mint the archive collection key from the console instead of by hand ... Setting a NAS up to collect the invoice archive meant three machines and a dozen commands: generate a keypair there, carry the public half to the server, write it into authorized_keys with a restriction, install rsync, and get every path right on the first try. Every one of those steps was a place to be told "permission denied" with no clue which of the three was wrong. It was, and several times over. One button now. The panel asks, the host does it — because the host is where all of it lives: the home directory, ssh-keygen, rrsync, and the archive itself. The panel is www-data in a container and owns none of that, so it uses the mailbox it already uses for updates. The private half is shown exactly once, alongside the finished rsync command, and is never written to the database: it exists to be copied into a NAS, and storing it "for convenience" would put a working credential in every backup of that database. rrsync does the restricting, not a pinned rsync option string. That string differs between rsync versions and fails silently — a refusal with no reason given, which is the shape of the afternoon this replaces. If rrsync is missing the agent refuses rather than issuing an unrestricted key while the panel says it is restricted. rsync now comes with install-agent.sh, which already runs as root once per machine. It has to be on the HOST: a NAS connects by ssh and sshd starts `rsync --server` here, so without it the pull fails with "command not found" from a NAS whose own setup is perfectly correct. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 10:08:32 +02:00
nexxo	d8ff717cb5	Let a destination say how it is laid out and how long anything stays ... Two destinations doing two jobs. A handover directory a NAS collects from wants a folder per day and wants emptying — thirty days is enough to notice a NAS that stopped collecting, and keeping more only hides it. An archive on the NAS itself wants a folder per year and wants nothing deleted, ever. So both are per destination rather than global. Deleting is safe here in a way it usually is not, and that is worth saying plainly: the invoice is a frozen document in the database and its PDF is rendered from that on demand. Nothing is moved anywhere — it is copied, and anything removed from a directory can be produced again and re-exported. The directory is a handover point, not the record. keep_days is null by default and stays null unless somebody sets it: a retention rule nobody asked for is a deletion nobody expected. The prune only touches folders whose NAME is one of the two shapes this application writes, and leaves everything else alone — a prune that deletes what it does not recognise is how an archive loses something nobody was watching. It also skips a destination whose path is missing rather than acting on whatever is underneath an absent mountpoint. The shape is matched with a pattern before parsing rather than by handing nonsense to Carbon: under strict mode createFromFormat throws instead of returning false, so one folder somebody made by hand would have ended the whole prune instead of being skipped. The test with a foreign folder in it found that. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 03:08:27 +02:00
nexxo	f0ec2fe03f	Keep the SFTP credential on the row it belongs to, encrypted ... The first version put it in the credential vault. The vault refuses it, and correctly: it keeps a registry of fixed, documented credentials so the Secrets page can describe each one, and a per-destination password is not that. Forcing a dynamic key into that registry would have made the registry meaningless. Encrypted onto the row with the same cipher instead — the same key, so it is no more readable in a database dump than anything the vault holds, and it lives with the record it describes. A rotated SECRETS_KEY now says so by name rather than surfacing as an authentication failure against a host that is perfectly fine. Also answers the question that prompted this: the host, port and user fields are there, and appear once SFTP is chosen. A mounted directory has no host on purpose — the mount is made on the server with mount(8), and the application only names the directory it writes into. A test asserts both halves, because "the fields are there, you just cannot see them yet" is not something anybody should have to take on trust. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 02:46:06 +02:00
nexxo	b3081a544b	Let the export have as many destinations as somebody wants ... One path and one exported_at could not say "on the office NAS, not yet on the off-site box" — which is the only interesting question once there is more than one destination, and the reason for a second is precisely that any single one can fail. A row per destination now, and a row per (invoice, destination) pair. Two kinds, and the difference is where the protocol lives. 'local' is a directory this machine can already write to: a NAS mounted over NFS 4.1, a bind mount, a disk. The application knows nothing about the protocol, the target changes without code changing with it, and the whole thing stays testable against a temporary directory. 'sftp' is for something reachable with credentials — a Hetzner Storage Box being the obvious one — and the password goes into the secret vault with only its key on the row, because a credential in a settings table is a credential in every database dump. An empty password field on an existing target means unchanged, not cleared: the field cannot show what is stored, so blank-means-delete would wipe it on every unrelated edit. One job per pair rather than one per invoice. A job writing to both would retry the one that worked every time the other did not, and report one outcome for two different things. The ordering fix the tests found: Laravel's local adapter creates its root when it is CONSTRUCTED, so the "never create the root" guard was checking a directory the disk had just made for it. It runs before the disk is built now. That guard is the difference between an archive and a hole in the ground — mkdir on an absent mountpoint succeeds, writes onto the container's own disk and reports success, and an archive that silently is not the archive is worse than none. The single path from the previous commit is migrated into a destination called "Archiv" rather than dropped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 02:43:15 +02:00