Understand Delivery Note limitations and unsupported possibilities

Identify features the supplied version 1.0.0 does not implement so users are not misled.

What this guide covers

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.

Exact step-by-step process

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, choices and supported possibilities

• 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

Code-backed validations and workflow rules

• 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.

Expected result and verification

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

Checks, security and troubleshooting

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

Related Delivery Note guides