Understand client invoice access checks
Know every branch that authorises or denies the client-facing PDF action.
Exact navigationClient Portal → Invoices → Open invoice
What this guide covers
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.
Exact step-by-step process
- Confirm the invoice exists and has a non-empty stored hash.
- Confirm the route hash exactly matches when hash access is used.
- Otherwise confirm the logged-in client ID matches the invoice client ID.
- Confirm a non-void note exists.
- Test the button and PDF in the correct customer context.
Fields, choices and supported possibilities
- 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
Code-backed validations and workflow rules
- 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.
Expected result and verification
- Only the intended client context or exact valid invoice hash can reach the client PDF controller.
Checks, security 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.