knowledge(events): database trigger setup flags may only be set to true

[Michael Dieringer (MichaelDieringer)]

Summary

• events/database-trigger-setup-flags-may-only-be-set-to-true. GetDatabaseTableTriggerSetup on the system codeunit Global Triggers and OnAfterGetDatabaseTableTriggerSetup on codeunit 49 GlobalTriggerManagement pass the same four var Boolean flags through every subscriber, and subscribers run in no particular order. A subscriber that assigns false, or a lookup result such as OnDatabaseModify := MySetup.Get(TableId), can clear flags set by Dataverse sync, API webhooks, data archive, or another app. A direct Global Triggers subscriber can also clear the change log flags. The compiler does not catch this.
  • Change log protection is narrower than it looks. GlobalTriggerManagement.Codeunit.al lines 51-65: codeunit 49 asks the change log last, and only in the normal execution context (62-64), next to its "don't allow anyone to disable change log" comment. That protects only against OnAfterGetDatabaseTableTriggerSetup subscribers.
  • BCApps subscribers only ever set the flags to true: Change Log Management 85-88 (with or), API webhooks 224-227, CRM 3748-3753, Master Data Management 1511-1516, Data Archive 27-32, GP migration 11-21. The no-op if not Delete then Delete := false; is carved out.
  • Two places in BCApps do clear flags, and the article names them: the demo data tool (W1 343-344, CZ 353, IN 357) and the Backup Management test library (470-476). They are the same mechanism in demo and test sessions, where clearing is acceptable. The review check carves them out.
  • One premise is inferred, and the article says so. Learn does not state that the events are raised only when the flag is true. The article infers it from:
    • Learn's integration-record refactoring page: subscribing to global triggers disables bulk SQL insert, modify and delete for that specific table.
    • The per-table cache comment in the BCApps change log test.
    • No Transactions Subscriber, which turns on every flag in order to see every write.
  • Recommended path: codeunit 49's integration events, following Learn's transition guidance against subscribing directly to system codeunits 2000000001..2000000010. When the set of tables is known, use table-specific mechanisms instead.
• Wiring: added to al-events-review (tokens plus an event-design check) and registered in the events review-fixtures override.
• Samples: good and bad samples checked with AL compiler 30.0 against Base Application 28.4 symbols.

Applicable versions: 15 and later.

Test plan

• validate_frontmatter.py: 0 errors (2 warnings, both in files this PR doesn't touch)
• Test-KnowledgeIndex.ps1, Test-SkillIndex.ps1, Test-KnowledgeRetrieval.ps1, Test-ReviewContract.ps1
• Test-ReviewFixtures.ps1: 230 cases

🤖 Generated with Claude Code

[Jesper Schulz-Wedde (JesperSchulz)]

Reviewed d3aa24d22607bfb26e82069d3aff547e1e966020. The additive setup-flag guidance matches the GlobalTriggerManagement chain: subscribers share the four var Booleans, and codeunit 49 adds change-log flags last only in normal execution context. The rule correctly distinguishes potentially clearing a prior true value from monotone/no-op assignments and explicitly excludes the documented demo/test-session cases. The good handler scopes itself to its own tracked tables. Samples, routing and deterministic positive/clean registration are consistent; exact-head local frontmatter, fixture/contract, skill/schema and knowledge-index/retrieval checks pass. No merge-critical issue found. GitHub's substantive workflows still await approval and should run before merge.