Understand Delivery Note asset and hook scoping
Verify that CSS and JavaScript load only where the module code requires them. 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 goTechnical inspection → Delivery Note hooks and invoice/module pages
What you’ll accomplish
Verify that CSS and JavaScript load only where the module code requires them. This guide follows the supplied Delivery Note module’s live hooks, controller actions, model rules, views and stored side effects.
Follow these steps
- Go to a non-invoice admin page and confirm Delivery Note assets are absent.
- Go to the Delivery Note register and confirm its CSS/JavaScript load.
- Go to an invoice editor and confirm invoice UI assets load only when enabled.
- Go to an eligible client invoice and confirm only the client button asset is injected.
Fields and options to review
- Admin head/footer hooks
- Customer head/footer hooks
- Invoice add/update filters and actions
- Asset version query derived from file modification time
Rules the system enforces
- The master enabled option gates all hooks.
- Admin assets are limited to module pages or eligible invoice pages.
- Client assets load only when an authorised invoice has a non-void note.
- The module makes no core theme or server changes.
How to confirm it worked
- The feature works without unnecessary global asset loading or unrelated UI effects.
Safety checks and troubleshooting
- Treat `_safe_backup_*` and unused public JavaScript as excluded implementation artefacts, not active features.
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.