f00cbf18d3
tests / pest (push) Failing after 7m59s
Details
tests / assets (push) Successful in 23s
Details
tests / release (push) Has been skipped
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> |
||
|---|---|---|
| .. | ||
| admin.php | ||
| admin_incidents.php | ||
| admin_settings.php | ||
| auth.php | ||
| backups.php | ||
| billing.php | ||
| capacity.php | ||
| checkout.php | ||
| cloud.php | ||
| coming_soon.php | ||
| common.php | ||
| customer_detail.php | ||
| customer_message.php | ||
| dashboard.php | ||
| datacenters.php | ||
| delivery.php | ||
| devices.php | ||
| domain.php | ||
| edit_customer.php | ||
| errors.php | ||
| finance.php | ||
| hosts.php | ||
| impersonate.php | ||
| inbox.php | ||
| instances.php | ||
| integrations.php | ||
| invoice.php | ||
| invoice_mail.php | ||
| invoices.php | ||
| invoices_admin.php | ||
| mail.php | ||
| mail_log.php | ||
| mail_settings.php | ||
| maintenance.php | ||
| new_invoice.php | ||
| order.php | ||
| orders.php | ||
| plans.php | ||
| provisioning.php | ||
| reset_password.php | ||
| secrets.php | ||
| security.php | ||
| sessions.php | ||
| settings.php | ||
| status.php | ||
| support.php | ||
| templates.php | ||
| two_factor_setup.php | ||
| updating.php | ||
| users.php | ||
| verify_email.php | ||
| vpn.php | ||
| withdrawal.php | ||