6 Commits (cfbe339df0940492995dbb343d3cb86d64c4daf0)

Author	SHA1	Message	Date
nexxo	d7d116e9a5	Jede Mail faehrt wieder ueber ihren eigenen Mailer ... Mail::to(...) loest den Standard-Mailer auf, und dessen queue() schreibt danach `$view->mailer($this->name)`. Damit war der im Konstruktor gewaehlte Mailer (cp_mail_<typ>) durch 'smtp' ersetzt, bevor der Auftrag ueberhaupt gebaut war. Mit dem Mailer fiel alles weg, was an ihm haengt: MailboxTransport, die Postfachsuche samt passendem Absender — und der Notschalter aus App\Support\MailDelivery, der genau dort sitzt. Eine abgeschaltete Zustellung schaltete deshalb nichts ab, und die Mails meldeten sich mit den Zugangsdaten aus der Konfiguration an, waehrend der Absender aus der Mail kam: „553 Sender address rejected". Das lief hier im Minutentakt. Zwei Stellen hatten es schon richtig — MaintenanceNotifier und MailPreview, beide mit der Erklaerung an der Zeile. Neun andere nicht. Alle beginnen jetzt mit Mail::mailer($mail->mailer), sodass das Ueberschreiben denselben Wert zurueckschreibt. Die Attrappen in drei Tests zielten auf to() und trafen damit nicht mehr den Einstieg; drei von ihnen bestanden ohnehin nur zufaellig, weil ein Aufruf auf null ebenfalls warf. Sie zielen jetzt auf mailer(). Erzwungen durch tests/Feature/MailDispatchTest.php: Mail::to( ist in app/ verboten, und ein Gegentest haelt das Framework-Verhalten fest, damit die Regel fallen darf, wenn Laravel sie eines Tages unnoetig macht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 20:36:20 +02:00
nexxo	c78866e360	fix(security): Aufheben einer Sperre sagt die Wahrheit und wird nachgeholt ... Mein eigener Befund "die Zeile erneuert sich nach dem Aufheben nicht" war falsch — eine Pruefung ueber den ganzen Weg (Modal schickt das Ereignis, Seite faengt es) zeigt, dass die Zeile sehr wohl in den Verlauf wandert. Dabei fiel der echte Fehler auf, der daneben lag: HostFirewall::release() schluckt jeden Fehlschlag und meldet ihn nur ins Log. Beide Aufrufer verwarfen den Rueckgabewert und meldeten in jedem Fall "Sperre aufgehoben." War der Host im Moment des Aufhebens nicht erreichbar, stand der Datensatz auf aufgehoben und die Regel noch drin: Portal und Konsole zeigten "Aufgehoben", waehrend die Adresse weiter ausgesperrt blieb — bis zum Ablauf der urspruenglichen Sperrzeit, ohne dass es jemand sagen konnte. - release() gibt zurueck, ob die Firewall schon nachgezogen hat; alle drei Stellen (Portal, Host-Ansicht, Kunden-Ansicht) sagen es, wenn nicht. - releaseMany() als Gegenstueck zu blockMany(): eine SSH-Sitzung statt einer je Adresse. - ScanForIntrusions gleicht jetzt in BEIDE Richtungen ab. Bisher trug er nur ein; nichts nahm je einen haengengebliebenen Eintrag wieder heraus. Eine Adresse, die eine ANDERE aktive Sperre desselben Hosts noch traegt, bleibt stehen. - Jeder Loeschbefehl traegt `2>/dev/null || true`: nft scheitert am Loeschen eines Elements, das es nicht gibt, und weg ist genau das Ziel. Ohne das meldete der Abgleich bei jedem Lauf einen Fehlschlag. 8 neue Pruefungen, Suite 2625 gruen.	2026-08-03 17:28:28 +02:00
nexxo	51a97019a8	Sperren sehen und aufheben: Portalseite fuer den Inhaber, Abschnitte in der Konsole ... Aufgabe 6 des Fruehwarnsystems. Der Inhaber sieht im Portal die Sperren SEINER Instanzen und hebt sie dort auf; der Betreiber sieht in der Konsole alle, an der Kunden- und an der Host-Detailseite, und auf der Uebersicht steht ein Hinweis, solange irgendwo eine Sperre aktiv ist. Aufgehoben wird ueber ein Bestaetigungs-Modal (R23), und das Modal mutiert nichts: es wirft ein Ereignis, das die Seite auffaengt und an ihre eigene Methode weiterreicht. Die Berechtigungspruefung bleibt damit an der einen Stelle, an der sie schon stand — noetig, weil ein Modal ohne die Middleware der Seite erreichbar ist (R20). Dazu die Berechtigung `instances.manage`, nach dem Muster der bestehenden `instances.restart`-Migration; Abrechnung und Read-only bleiben unberuehrt. ACHTUNG, was hier sonst noch drinsteckt und NICHT zu dieser Aufgabe gehoert: rund 150 Zeilen zum Versandtakt — das Merkmal `RidesALane`, vierzehn Mailables und `MailLaneRoutingTest`. Die stammen aus einer PARALLEL laufenden Sitzung an einem anderen Feature. Wie das hineingeriet: der Implementierer dieser Aufgabe brach vor dem Commit ab und liess seine fertige Arbeit ungespeichert im Baum. Ich habe sie dateigenau mit `git add <dateien>` vorgemerkt, um nichts Fremdes mitzunehmen — und dabei uebersehen, dass `git add` nur HINZUFUEGT: die andere Sitzung hatte ihre Arbeit bereits vorgemerkt, und `git commit` schreibt den ganzen Index, nicht nur das zuletzt Hinzugefuegte. Richtig waere `git commit -- <dateien>` gewesen. Nichts ist verloren, und die volle Suite ist auf diesem Stand gruen (2571). Aber diese Botschaft soll nicht behaupten, sie beschreibe alles, was hier steht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 15:53:24 +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	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	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