Understand Delivery Note route options and safety fallbacks
Interpret the installed route options and helper validation without presenting a nonexistent settings screen.
Exact navigationNo staff-menu screen exists → Authorised deployment/configuration review
What this guide covers
Interpret the installed route options and helper validation without presenting a nonexistent settings screen. 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
- Review the default admin, public-view and public-sign option values.
- Use the helper-generated admin and public URLs in module code.
- Confirm configured public route values do not use legacy/hyphen forms rejected by the helper or contain `admin/`.
- Test generated links after any approved change.
- Restore defaults when validation falls back unexpectedly.
Fields, choices and supported possibilities
- delivery_note_admin_route
- delivery_note_public_view_route
- delivery_note_public_sign_route
- delivery_note_route_mode
Code-backed validations and workflow rules
- The helper normalises slashes and rejects unsafe public route values.
- Default public view/sign values are `delivery_note/public_view` and `delivery_note/public_sign`.
- Routes.php contains compatibility aliases, but current generated links use the supported controller/query-token pattern.
- There is no user-facing route settings form.
Expected result and verification
- All admin and recipient links resolve through approved module routes without creating an admin exposure.
Checks, security and troubleshooting
- Do not change core routes or `.htaccess` to compensate for an invalid module option.
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.