b6da405376
Lead with a complete plugin quick start and add task-oriented usage, troubleshooting, customization, and contribution guides. Preserve the broader plugin framing, correct conflicting contract guidance, support Agents folder reviews, and align repository validation. Convert existing sample references to clickable links without changing knowledge rules. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
1.6 KiB
| bc-version | domain | keywords | technologies | countries | application-area | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
upgrade |
|
|
|
|
OnUpgradePerCompany / OnUpgradePerDatabase should call helpers, not inline logic
Description
The OnUpgradePerCompany and OnUpgradePerDatabase triggers on an upgrade codeunit are dispatch points, not implementation slots. They should contain only calls to named local procedures — one call per feature being upgraded. Putting ModifyAll, record loops, or any business logic directly inside the trigger body makes the upgrade impossible to read, impossible to selectively skip via upgrade tags per feature, and impossible to extend without touching the trigger itself.
Empty OnUpgradePerCompany / OnUpgradePerDatabase triggers are acceptable — they may be placeholders for future use or artifacts from cleanup.
Best Practice
Each upgrade trigger contains an ordered list of procedure calls, one per feature: UpgradeFeatureA(); UpgradeFeatureB();. Each procedure handles its own upgrade tag, its own data work, and can be added or removed independently.
See sample: triggers-call-helpers-not-implementations.good.al.
Anti Pattern
Implementing record loops, ModifyAll, or other data work directly in the trigger body. The trigger then mixes orchestration with implementation, and adding a second feature requires editing the trigger rather than appending one line.
See sample: triggers-call-helpers-not-implementations.bad.al.