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
This commit is contained in:
Darko Gjorgjijoski
2026-08-01 13:01:15 +02:00
committed by GitHub
parent 8ab860a1ae
commit 05e8acc3b1
11 changed files with 258 additions and 35 deletions

View File

@@ -4,6 +4,7 @@ namespace App\Support\Pdf;
use Illuminate\Support\Facades\File;
use Illuminate\Support\Facades\Storage;
use Illuminate\Support\Facades\View;
use Illuminate\Support\Str;
class PdfTemplateUtils
@@ -106,6 +107,28 @@ class PdfTemplateUtils
return array_values($formatted);
}
/**
* The view to render for a document, preferring a custom override.
*
* Invoices and estimates let you pick between several designs, so their
* template is chosen per document. Payment receipts and reports have no
* chooser and no design to pick, so overriding one means dropping a
* same-named file into storage/app/templates/pdf/{type}/ and having it win.
* That keeps the whole feature to "the file exists, so use it" and needs no
* setting, column or picker.
*/
public static function resolveView(string $templateType, string $templateName): string
{
$custom = sprintf('pdf_templates::%s.%s', $templateType, $templateName);
// View::exists rather than a disk check: the namespace is what actually
// renders, so asking it directly means the two cannot disagree about
// where custom templates live.
return View::exists($custom)
? $custom
: sprintf('app.pdf.%s.%s', $templateType, $templateName);
}
/**
* Returns custom template path
*