2 Commits (main)

Author	SHA1	Message	Date
nexxo	0a89695189	R24: a modal is never taller than the screen ... A modal grew with its content, so a form ran off the bottom of the window and took its own save button with it — reachable only by scrolling the page BEHIND the backdrop, which on a phone means not reachable at all. The customer form with its eight fields is what made it obvious, but it was true of every long modal in the console. Two halves. The panel is capped once, in the published package view, so no modal can opt out of it and none has to remember to: max-h in dvh rather than vh, because on a phone the browser's own chrome counts towards vh and that is exactly the case where the last centimetre decides whether the button can be reached. And x-ui.modal is the other half — a header slot, a scrolling body, a footer slot. min-h-0 on the body is the line that makes it work: a flex child will not shrink below its content without it, and the overflow never engages. Fourteen modals converted: the ones that carry a field, which are the ones that can grow. A two-line confirmation with one button has nothing that needs to stay put, and the rule says so rather than leaving a footnote — the test's criterion is the field, so the moment somebody adds an input to a confirmation it fails and tells them. A submit button in a footer sits outside the form it submits, so it carries form="…". That is the price of a footer that does not scroll away, and an HTML attribute rather than a workaround; there is a test for it, because without it the button silently does nothing. Two traps met on the way, both now scanned for. A Blade directive in a component tag's attribute list (a conditional wire:poll on x-ui.modal) compiles into the attribute bag and breaks the view outright — the same mistake as @disabled on x-ui.button, which cost a debugging round earlier this session; such attributes go on an element of their own. And Pest's toContain() is variadic, so the second argument I passed as a failure message was read as another needle: the assertion demanded that a footer contain its own filename, and failed on a file that was correct. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 23:33:57 +02:00
nexxo	e6d2e6dc33	Give the console a Finance tab: company details, VAT rate, invoice series ... Its own tab rather than a section of Settings, as asked. What is set here appears on a legal document, and burying it beside the site-visibility switch invites somebody to change one in passing. Everything the printed invoice needs — registered name, address, Firmenbuch number and court, VAT ID, bank details, payment terms, logo — with the logo replaceable, because a company changes its mark. None of it reaches an invoice that already exists: the values are copied into each document when its number is assigned, so a corrected address is correct from the next one onwards and cannot rewrite an old one. The console refuses to consider itself ready while a name, an address or a VAT number is missing, and says which. An invoice without them is not a valid invoice in Austria, and issuing one is worse than refusing to. The series editor carries the same shape as EditDatacenter and for the same reason. The prefix is free while the series is empty and frozen once a document carries it: changing RE to AR renames nothing and leaves a series whose past says RE and whose future says AR, with no record they belong together. The counter may be raised — an operator migrating from another system needs exactly that — but never lowered, because a lower number is one already printed on a document somebody holds. Both rules are recomputed from the database on save rather than read back from the properties the browser returns. CompanyProfile drops keys that are not part of the profile. It is fed from a form, and a forged key must not be able to write an arbitrary setting into the same table the site-visibility switch lives in. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 01:18:43 +02:00