Understand client invoice access checks
This guide explains that every branch that authorises or denies the client-facing PDF action. The guide then takes you through the correct route, the checks to complete before making changes, the workflow in order, and the evidence to review afterwards.
Where to goClient Portal → Invoices → Open invoice
What you’ll accomplish
Know every branch that authorises or denies the client-facing PDF action. This guide follows the supplied Delivery Note module’s live hooks, controller actions, model rules, views and stored side effects.
Follow these steps
- Verify the invoice exists and has a non-empty stored hash.
- Verify the route hash exactly matches when hash access is used.
- Otherwise confirm the logged-in client ID matches the invoice client ID.
- Verify a non-void note exists.
- Test the button and PDF in the correct customer context.
Fields and options to review
- Exact invoice hash comparison uses `hash_equals` when available
- Logged-in client ownership fallback
- Invoice ID derived from route/query context
- Active note lookup excludes void
Rules the system enforces
- A blank invoice hash is not accepted as hash authorisation.
- The client hook does not add assets or a button when no eligible note is found.
- A signed note remains active and can have a PDF; a void note does not.
How to confirm it worked
- Only the intended client context or exact valid invoice hash can reach the client PDF controller.
Safety checks and troubleshooting
- Never weaken the check to make a missing button appear.
Stay within the supported flowDo not force database values, expose secure tokens, bypass permission checks, replace a stored signature or invent a status or interface that the supplied code does not implement.
Continue with related guidance
Was this guide useful?Your response is stored only in this browser.