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: Jesper Schulz-Wedde <jesper.schulzwedde@microsoft.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
1.4 KiB
| bc-version | domain | keywords | technologies | countries | application-area | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
performance |
|
|
|
|
Guard page trigger work with GuiAllowed for OData and Excel
Contributions welcome — open a PR to refine or extend this article.
Description
Pages exposed as OData, including Edit in Excel, still run AL page triggers for every row returned. FactBox updates, defaulting, and extra CalcFields in OnAfterGetRecord therefore run on the web-service path where no UI exists. GuiAllowed is false for those sessions. Agents add page logic as if only the browser client will execute it.
Best Practice
Wrap UI-only work — FactBox refresh, notifications, defaulting that is not part of the web-service contract — in if GuiAllowed then. Keep the OData path to field values the API actually returns.
See sample: guiallowed-guard-on-pages-used-as-odata.good.al.
Anti Pattern
Unconditional FactBox or calculation logic in OnAfterGetRecord / OnAfterGetCurrRecord on a page that is published as a web service or used with Edit in Excel. The signal is trigger work that calls CurrPage parts or extra queries without a GuiAllowed guard.
See sample: guiallowed-guard-on-pages-used-as-odata.bad.al.