Understand void-action visibility and permission
Distinguish the implemented controller capability from the buttons actually present in the supplied UI.
Exact navigationAdmin Area → Setup → Staff → Roles → Delivery Note → Delete
What this guide covers
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.
Exact step-by-step process
- Grant Delete only to approved roles.
- Review 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, choices and supported possibilities
- Delete capability maps to void controller
- No hard-delete controller
- No visible void button in supplied detail/list views
- Signed status remains non-voidable
Code-backed validations and workflow rules
- 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.
Expected result and verification
- Administrators understand the real code possibility without misleading staff about current UI.
Checks, security 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.