Understand void-action visibility and permission
Distinguish the implemented controller capability from the buttons actually present in the supplied UI. 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 goAdmin Area → Setup → Staff → Roles → Delivery Note → Delete
What you’ll accomplish
Distinguish the implemented controller capability from the buttons actually present in the supplied UI. This guide follows the supplied Delivery Note module’s live hooks, controller actions, model rules, views and stored side effects.
Follow these steps
- Grant Delete only to approved roles.
- Check the supplied admin view and confirm no Void button is displayed.
- If the organisation exposes the controller action, add it only through an approved scoped implementation with confirmation and CSRF protection.
- Test that signed notes remain protected.
- Document the deployed interface accurately.
Fields and options to review
- Delete capability maps to void controller
- No hard-delete controller
- No visible void button in supplied detail/list views
- Signed status remains non-voidable
Rules the system enforces
- The Help Centre must not invent a visible path that the module does not implement.
- Capability existence does not prove a button exists.
- Any later UI addition should preserve the model’s signed lock and audit event.
How to confirm it worked
- Administrators understand the real code possibility without misleading staff about current UI.
Safety checks and troubleshooting
- Treat this as a technical action reference, not a standard clickable user workflow in the supplied build.
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.