Understand Delivery Note limitations and unsupported possibilities

Identify features the supplied version 1.0.0 does not implement so users are not misled. 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.

What you’ll accomplish

Identify features the supplied version 1.0.0 does not implement so users are not misled. This guide follows the supplied Delivery Note module’s live hooks, controller actions, model rules, views and stored side effects.

Follow these steps

1. Use the documented create, view, edit, sign, void, PDF and client-access flows.
2. Treat listed omissions as unavailable unless a later verified release adds them.
3. Check the deployed module version before promising a feature.
4. Update documentation only after code inspection.

Fields and options to review

• No cron/background scheduling
• No API or webhook
• No CSV export or analytics report
• No hard-delete controller
• No manual email resend UI
• No token expiry, rotation or revocation
• No public signatory-name/email fields
• No visible Void button in supplied admin view
• Register limited to newest 100
• Installed PDF footer-text option not used by renderer
• Active sign model validates non-empty signature content but not its data-URI format or dimensions
• Public controller, not the active model alone, blocks void-note signing

Rules the system enforces

• Backup files and dead controller methods are not active features.
• An unused JavaScript file does not prove a visible workflow.
• Database columns that are never populated must not be described as captured data.

How to confirm it worked

• Staff and customers receive accurate expectations based on the supplied code.

Safety checks and troubleshooting

• Do not invent workarounds that bypass security, status or audit controls.

Continue with related guidance