8 Commits

Author	SHA1	Message	Date
Darko Gjorgjijoski	00c9c4268e	fix(pdf): give the reports their margin back, and one shared chrome (#738) ... * fix(pdf): put the page margin back on the report PDFs The report templates carry no inset of their own. They set `.sub-container { padding: 0px 20px }` and nothing else, and relied entirely on dompdf's built-in 1.2cm page margin. #727 made DompdfDriver always inject an `@page` rule from PdfPageSetup, and #735 defaulted those margins to zero so invoice2 and estimate2 could bleed their header band to the paper edge. The document templates were fine, they carry their own 30px/50px insets. The reports were not: every one of them now renders flush against the paper, with the company name's glyph box actually clipped 1.2pt above the top edge. The zero default has to stay for documents, so reports get a margin of their own: `pdf.page.report_margin`, PDF_REPORT_MARGIN, defaulting to the 1.2cm they were drawn against. It is a separate key on purpose, so an operator tuning the document margins for their invoice template does not silently reflow every report as a side effect. A page margin rather than padding on the templates because reports run to several pages and padding only insets the first one. Sales by customer already spans two on the demo data, and page two moves with the rest. Plumbed as an optional PdfPageSetup on the driver contract, defaulting to the configured page, so every existing call site renders exactly as before and only the five report controllers ask for anything different. Measured on the five reports, page 595.28 x 841.89pt, 1.2cm = 34.02pt: first page ink moves from xMin 15.0-15.8 / yMin -1.2 to xMin 49.0-49.8 / yMin 32.8, every axis shifting by exactly the margin. Also fixes three untranslated keys this exposed: the expenses report printed its column headings as the literal strings "expenses.date", "expenses.note" and "expenses.amount", which have never existed in lang/en.json. They are now pdf_expense_{date,note,amount}_label, and a test pins that every translation key a report template uses resolves in English. * fix(pdf): put the minus sign in front of the currency symbol format_money_pdf() formatted the signed value and then concatenated the symbol, so a negative amount came out as "$-24,738.00". Credit notes made that common: every line on a credit note PDF reads negative, and one credit note in a period is enough to make the customer sales report show a negative total. The magnitude is formatted first now and a single minus is prefixed to the whole assembled string, so the sign leads and the symbol stays glued to the digits. Only the symbol-first branch changes. number_format() already put the sign in front of the digits, so a trailing-symbol currency read "-24,738.00$" before and is byte-identical after. The sign is decided on the formatted digits rather than on the raw input, so an amount that rounds away at the currency's precision renders as zero rather than as "-0". A stray cent on a zero-precision currency is the case that needs it. * refactor(pdf): one shared chrome for the report PDFs The five report templates were five drifted copies of one 2018 stylesheet, and the insets had stopped agreeing with each other. profit-loss alone put its header and income row at +20px, its "Expenses" heading at +23px, its category rows at +30px, and its total rule and NET PROFIT band at +0, because that markup sat outside the container everything above it was in. Four left edges on one page. Every report also carried the same self-cancelling total rule, where `padding: 0px` follows the two longhands it silently overrides, and expenses carried six rule blocks nothing referenced at all, including the only horizontal rule in the file. There is now one layout partial and one stylesheet, and each report is content only: 236 lines down to 47 for profit-loss, and about 1200 lines deleted across the five. One content edge, measured: every band starts at 34.016pt and every amount ends at 561.260pt, on every page of every report. What changed on the page: - Real tables with a thead, so column headings repeat across page breaks. Only expenses had headings before and none of them used thead. sales-items emitted a separate table per item, which is why its rows never lined up. - The company logo in the header, the same fallback-to-name pattern the document templates use. - An empty period renders a "no records" row. profit-loss, sales-items and tax-summary rendered their total row and rule unconditionally, so a month with no data showed a heading, a gap, a rule and a lone $0.00. - Sections stay whole across a page break where they fit, and a section heading never sits at the foot of a page with its rows overleaf. - Credit notes stay in the sales totals, since a reversal netting the sale out is correct, but the line is tagged so a CN- number is not read as a sale. It reuses the document's own label, which is already in the shipped locales. - Labels stopped carrying their own presentation: "TOTAL EXPENSE" (also singular) is "Total expenses" and the stylesheet does the uppercasing. The five controllers drop the dead colour-settings block: nine *_color settings were queried and shared by every report, no template ever read them, and no migration, seeder or UI ever wrote them, so the query always returned an empty collection. Every other shared variable name is untouched, because a custom report template is a copy that references them by name. make:template had to learn the same lesson: it only ever copied partials/table.blade.php, so a cloned report would extend a layout that does not exist in its namespace and die on render. It now copies every partial a type ships and rewrites references by view name, including partial-to-partial ones, so each custom template still gets its own copies.	2026-08-02 14:34:02 +02:00
Darko Gjorgjijoski	885042f13a	feat(expenses): add tax tracking and reporting (#737)	2026-08-02 13:01:01 +02:00
Darko Gjorgjijoski	bd9602b130	fix(pdf): stop an unresolvable template taking the PDF route down (#735) ... * fix(pdf): stop an unresolvable template taking the PDF route down RealisticDemoSeeder::seedEstimate() never set template_name, while seedInvoice() has always set invoice1. Every demo estimate therefore had '', so findFormattedTemplate() returned null and EstimateService did $template['custom'] on it -- a 500 on the estimate PDF route, on either driver, since the exception is thrown before a driver is reached. That is the "Unable to load document preview" people were seeing. The seeder now sets estimate1, but seeding was only how this surfaced. The stored name is validated when a document is saved through the UI and nowhere else: seeders, imports, recurring-invoice copies and rows predating that validation all bypass it, and a template can also be deleted from disk after the fact. A name that cannot be resolved should fall back to the default design, not take the route down. PdfTemplateUtils::resolveView() -- already the resolver for payment receipts and reports -- gains an optional fallback and tries each candidate as custom then built-in. Both document services collapse to a single call and can no longer index null. The fallback logs a warning, so a bad name stays visible rather than being silently swapped. Also casts two nulls in GeneratesPdfTrait: an address line or custom field that was never filled in reaches htmlspecialchars() and strtr() as null, which every PDF render was emitting a deprecation for on PHP 8.4 and would be an error on 9. Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF * feat(pdf): a command that measures the two drivers against each other "The PDF looks different" has been diagnosed by eye every time, because nothing compares the renderers. Asserting on PDF bytes is useless and rendering through Gotenberg needs a live service, so the suite has never covered it. pdf:compare renders each stock template through both drivers and reports the page box, page count and the bounding box of the text on page one, then flags any template whose ink lands more than --tolerance points apart. It goes through the real document services, so it exercises the same shared view data and template resolution a request would. Two things it has to get right to be honest: Comparing designs means persisting the template choice -- InvoiceService reads it back with Invoice::find($id)->template_name, so assigning in memory silently compares the same design every row. The run happens inside a transaction that is always rolled back. Page numbers are turned off for the duration. They are a Chromium capability with no dompdf equivalent, so leaving them on puts ink at the foot of every Gotenberg page and drowns out every difference worth seeing -- which is exactly what the first run of this command did. Word positions come from poppler's pdftotext, which is on most dev machines but not in the app container; without it the command still compares page geometry and says what it could not check. Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF * fix(pdf): let the two renderers agree on the items table, and drop the shim Two parts: the stock templates stop doing their own page margins, and the items table stops relying on a property that does not apply to it. Page margins. The templates carried their own via `html { margin-top: 50px }`, which predates page setup owning them. dompdf largely collapses that margin; Chromium honours it and adds it to the page box, so the same template came out 38px from the top on one renderer and 77px on the other. The html rule is gone and body is reset instead, which is what makes the page box agree. Headers that were positioned absolutely at a negative offset -- only possible because of that margin -- are back in flow. The items table. Every stock template sets `table { border-collapse: collapse }`, and CSS says padding does not apply to a table in that mode. dompdf applies it anyway; Chromium follows the spec and drops it, so the table's `padding: 0 30px` inset the content on one renderer and not the other. Measured in isolation: with border-collapse, content starts at x=24.0 on dompdf and x=1.5 on Chromium -- the full 30px. All of the table's spacing moves to .items-table-wrapper, a plain block both engines treat the same, using padding so nothing collapses through it either. Measured across the seven document templates, that closes the horizontal gap outright: xMin was 57 on dompdf against 37 on Chromium for five of them, and is now within 3pt on all seven. GotenbergStockTemplateCompatibility is removed. Its premise was that dompdf inflates declared line heights by 1.5x, and that does not hold: rendering the same text at 12px, 18px, 36px and unitless 1.0/1.5 through both engines gives line spacing within 0.5pt every time. It also applied its multiplier to the reports, where line-height 21px pairs with font sizes of 14, 16 and 20px -- so .report-footer-value at a 1.05 ratio was being blown out to 31.5px, half again taller than dompdf renders it. A residual vertical difference remains and is localised, not guessed at: it accumulates only in the address blocks, which are <br>-joined text emitted by getFormattedString() with an <h3> in front. Reduced to that construct alone, Chromium steps 11.25pt per line -- exactly the declared line-height: 15px -- while dompdf steps 14.4pt. That needs deciding on its own terms rather than a global multiplier, so it is left visible and measurable via pdf:compare. Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF * fix(pdf): restore the stock template design Two regressions from the page-setup work, both visible on the page. The coloured header band stopped bleeding to the paper edges. invoice2 and estimate2 are built around a full-width band, and it now sits in normal flow at the top of body, so it only reaches the edge when the page margin is nothing. #728 defaulted margins to 1.2cm on the reasoning that it matched dompdf's built-in default and so kept existing output unchanged. That was the wrong reference: the templates are drawn for a zero margin and carry their own 30px insets, and Gotenberg rendered them at zero before #728, which is the intended look. Margins now default to nothing. Setting one still works and is honoured by both drivers, at the cost of the band no longer reaching the edge. A bare `0` is valid CSS and the only length needing no unit, so CssLength and PdfPageSetup accept it -- without that the new default would have thrown on every render. The totals block was pushed in from the items table's right edge. Fixing the border-collapse padding problem moved the table's 30px inset onto a wrapper that contains the whole partial, so it stacked on the insets the hr (25px) and the totals container (25px) already had. Those two were always honoured by both renderers; only the table's own padding was not. The inset now lives on a div wrapping just the table, and the wrapper keeps vertical spacing only, which restores the original 30px/25px relationship rather than inventing a new one. Also drops the negative margin-bottom that pulled the addresses up into the band and hid "Bill to,", and removes a stray `bottom: 0px` on invoice1's .header-bottom-divider that combined with `top: 90px` to stretch the rule down the page. Checked by rendering, not only by measurement: invoice2 and invoice1 on both drivers now match the intended design. pdf:compare puts the two renderers within a few points horizontally on all seven documents, xMin 21-22 and xMax 564-575. The remaining vertical difference is the address-block line spacing documented earlier and is unchanged by this. Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF * feat(demo): make the demo data actually demo the product The demo company had no address row, and Invoice::getCompanyAddress() returns false outright in that case, so every seeded document rendered with an empty company block -- the name only appeared because the header falls back to it when there is no logo. Several headline features had no demo data at all: zero tax types, zero notes, zero recurring invoices, zero custom fields. DemoSeeder, which the test suite and reset:app both run, now creates Acme Inc with a postal address, tax ids and a country -- the fields the default address format actually renders. The address is created through the relation, as CompaniesController does, so company_id is set and type/user_id/customer_id stay null: Company::address() is an unscoped hasOne, so anything else carrying that company_id would be picked up as the company's own. It also stops trusting currency id 1. Migration 2025_08_18 inserts Algerian Dinar via firstOrCreate() before any seeder runs, so on a fresh migrate+seed the demo priced everything in "DA". RealisticDemoSeeder already worked around this for itself; resolving USD by code fixes it at source for reset:app and the tests too. RealisticDemoSeeder gains a logo, two tax types, a notes library, custom fields and an active recurring invoice. Notes are seeded twice over on purpose: the library and a document's notes column are unrelated in this application -- there is no foreign key, and is_default only drives a badge in the settings list, so nothing pre-fills a document with one. Tax is applied at document level to most but not all documents, so the demo has a zero-rated example in it. The arithmetic is the caller's: the service layer trusts whatever amount it is handed rather than recomputing it, so tax is rounded once off the subtotal and carried through total, due_amount and every base_* twin -- miss due_amount and a paid invoice renders as part-paid. Custom fields are on Customer, the only model_type with a create/edit UI end to end. The PDF renders only model_type 'Item', which would add a column to the items table and disturb a layout that was just squared up across both drivers. The logo is a generated Acme mark rather than one of InvoiceShelf's own, which would read as InvoiceShelf billing the customer. Also documents both seeders in AGENTS.md. RealisticDemoSeeder was referenced nowhere outside database/seeders/, which is a poor place to keep the thing that makes the app look real. Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF * fix(pdf): tighten the spacing the old absolute header left behind invoice2 and estimate2 carried three stacked top offsets -- content-wrapper's 60px margin plus address-container's 18px margin and 20px padding -- 98px of dead white between the coloured band and the first line of content. They existed because the band used to be position: absolute and out of flow, so everything below had to be pushed clear of where it visually sat. The band takes its own height now, so the compensation is just a gap. Collapsed to a single 32px. Only those two templates had it, which is the tell: they are exactly the two whose headers were absolutely positioned. Also pins the margins on the <h3> the address formats emit. Left to the user-agent default it pushed the company column out of line with the Bill to / Ship to columns beside it, so the three column headings started at three different heights. They line up now. That h3 is also where the two renderers were measured drifting apart, and pinning it narrows invoice2 from 85.8pt to 72.0pt and estimate2 from 84.4 to 76.8. The templates without a coloured band barely move, which places the rest of the difference in the per-line spacing of the <br>-joined address lines rather than in the heading -- consistent with the isolated measurement earlier (dompdf 14.4pt per line against Chromium's 11.25pt) and still open. Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF	2026-08-01 14:45:58 +02:00
Darko Gjorgjijoski	05e8acc3b1	feat(pdf): let payment receipts and reports be overridden too (#731) ... Only invoices and estimates could be customised. Payment receipts and all five reports were hardcoded to app.pdf.*, so changing them meant editing files inside the image -- and losing the edit on the next upgrade. Those documents have no template picker and no design to choose between, so overriding one is not a selection: it is a same-named file in storage/app/templates/pdf/{type}/ winning over the built-in. PdfTemplateUtils:: resolveView() is that rule, and it needs no setting, no column and no UI. resolveView asks View::exists rather than checking the storage disk. The disk and the view namespace are registered separately and could disagree about where custom templates live; asking the thing that will actually render removes that possibility. make:template covers the new types. Their names are not free, since an override replaces one specific document, so it validates against the real list -- 'payment' for payments, and the five report names -- and reports what is available when the name is wrong. Neither type gets a preview image written, having no picker to show one in. The payment preview route also went through the built-in view directly rather than the service, so ?preview ignored an override and rendered with none of the shared data. It goes through the service now, like invoices and estimates. Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF	2026-08-01 13:01:15 +02:00
Darko Gjorgjijoski	8ab860a1ae	fix(pdf): make custom templates behave the way the docs describe (#730) ... Custom templates are a real feature with no test coverage at all, and several rough edges that only show up once someone actually uses one. make:template validated nothing. --type was checked only by the interactive prompt, so `--type=payment` skipped the prompt and died on an uncaught FileNotFoundException looking for payment1.blade.php: a stack trace instead of a message. The name was not checked either, so `../escaped` wrote outside the templates directory. Both are refused now. Every custom template of a type shared one partials/table.blade.php. It was written on first use and reused thereafter, so editing the items table for one custom template silently changed it for all of them -- a file that looks per-template and behaves globally. Each template now gets its own copy under partials/{name}/, and its include is rewritten to match. Existing templates keep including the old shared path, which still resolves. A custom template sharing a built-in's name appeared twice in the picker with the same label, and findFormattedTemplate() array_reverses and takes the first match, so the custom one silently won. The listing is keyed by name now, so it appears once, as the entry that will actually be used. A custom template with no same-named .png rendered <img src=""> in the picker: a blank tile, no error, no hint anything was missing. It falls back to the preview of the template it was cloned from. template_name was validated as `required` and nothing else, so any string was accepted and stored. findFormattedTemplate() returns null for an unknown name, the null reads as "not custom", and rendering falls through to app.pdf.{type}.{name} -- a raw "view not found" 500 at PDF time, long after the save that caused it. New PdfTemplateExists rule, scoped per document type. make:template also copies a _header/_footer companion when the source template has one, so a scaffolded template keeps the repeating page furniture. Both getEstimateTemplateName/getInvoiceTemplateName asked for the template list with the default image format, base64-encoding a preview of every template just to read the names back. Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF	2026-08-01 12:56:39 +02:00
Darko Gjorgjijoski	713e0bc2e8	feat(pdf): repeating page headers and footers, and page numbers (#729) ... Takes over #690 by csoscd. The companion-view idea is theirs; this reworks it onto the shared page setup and fills in the gaps that stopped it landing. A `{template}_header` or `{template}_footer` view next to a template is rendered alongside it and repeated by Chromium on every page. The suffix resolves through the pdf_templates:: namespace too, so custom templates get it with no extra wiring. Two things had to change for that to be useful. Companion views are now hidden from the template picker. getFormattedTemplates() lists every .blade.php it finds, so an invoice1_footer would otherwise appear as a separately selectable template with no preview image -- the feature would have introduced that the moment anyone used it. And it does something out of the box. #690 shipped no companion views, so both of its margin settings were visible no-ops until someone hand-wrote a Blade file. Instead there is a pdf_page_numbers setting, off by default, that supplies a footer when a template has none. A template's own companion still wins, so turning page numbers on cannot overwrite a designed footer. The setting sits under Gotenberg because only Chromium can repeat a footer; dompdf has no equivalent. Its value is still carried by the dompdf form so saving from there cannot clear the choice -- the field is absent from that payload, and the controller only writes it when present. Margins come from the page setup rather than #690's separate header_margin and footer_margin. Chromium draws header and footer inside the page margin, so the existing margins are the space they occupy; two more settings for the same distance would have been a second way to say the same thing. Verified against a live gotenberg:8 on a two-page document: off produces no footer, on produces "1/2" and "2/2" on the respective pages, and a companion footer replaces both. #690's own test is not carried over. It asserted nothing: a bare View::shouldReceive('exists') is an allowance rather than an expectation, andReturn(false) never entered the companion branch, and the call sat inside try { } catch (Throwable) { }, so it passed with the feature deleted. Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF	2026-08-01 12:52:47 +02:00
Darko Gjorgjijoski	6cb754da60	fix(pdf): give both drivers one contract, and fix what that was hiding (#727) ... PdfDriver and ResponseStream existed but nothing implemented them. The factory returned the vendor dompdf wrapper for one driver and a bespoke class for the other, so the two were never held to the same shape. Three things had slipped through that gap. Report PDFs answered 403 for everyone. The five report routes carry no company header, so ScopeBouncer is not in their middleware stack and the ability scope was never set; 'view-financial-reports' is stored scoped to a company, so the check could not pass. They now scope to the company named in the URL. The policy still checks membership, so this grants nothing new. Also firstOrFail() on the hash lookup, so an unknown company is a 404 rather than a 500 on a null. Report downloads were fatal on Gotenberg. GotenbergPdfResponse had no download(), and the report controllers are its only callers. Added, alongside stream() and output(), with the whole set now on the interface. Streamed documents carried an HTTP preamble. GeneratesPdfTrait wrapped $pdf->stream() -- already a Response -- in another response()->make(), which stringified it and prepended "HTTP/1.0 200 OK" plus headers to the file. Readers scan the first kilobyte for %PDF so nobody noticed, but the bytes were malformed. Passing ->output() fixes it, and the render test now asserts the position. Two driver-parity settings, both checked against a real gotenberg:8 rather than inferred: emulateScreenMediaType(), because Chromium defaults to print media while config/dompdf.php renders as screen, so a @media print rule applied on one driver and not the other; and printBackground(), which turns out to affect only the root background, since Chromium paints element backgrounds either way. No stock template sets a body background, so that one changes nothing today and is here to keep custom templates consistent across drivers. Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF	2026-08-01 12:43:31 +02:00
Darko Gjorgjijoski	403a4d6722	test(pdf): cover every stock PDF template, and silence the PHP 8.5 PDO deprecation (#696) ... * test(pdf): render every stock template through the real pdf routes Blade templates reference PHP classes as plain strings, so a namespace move leaves them dangling without Pint, the IDE, or CI noticing — which is how #695 shipped a fatal ImageUtils reference in all seven stock templates and left it there for three months. Renders each invoice, estimate and payment template end-to-end through the pdf routes with a company logo attached, since every template guards the logo behind `@if ($logo)` and the fallback branch never reaches ImageUtils. One extra assertion checks the rendered markup actually carries the base64 data URI, so a template that silently drops the logo fails too rather than emitting a valid but logo-less PDF. Template names are globbed off disk rather than hardcoded, so a new stock template is covered as soon as it lands. * fix(config): resolve the mysql SSL CA attribute per PHP version PHP 8.5 deprecated PDO::MYSQL_ATTR_SSL_CA in favour of Pdo\Mysql::ATTR_SSL_CA, so every test in the suite was reported as deprecated rather than passed — noise that would hide a real one. Pdo\Mysql does not exist before 8.5 and this package supports ^8.4, so the constant is resolved at runtime; the untaken ternary branch is never looked up, which keeps 8.4 working. The lookup stays behind the extension_loaded() check because neither name is defined when pdo_mysql is missing. Verified against both runtimes: with MYSQL_ATTR_SSL_CA set, 8.4 resolves to attribute 1009 and 8.5 to 1008 — each version's own value, matching what the previous code produced there.	2026-07-28 19:58:34 +02:00