mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-06 15:16:56 +01:00
2f3e5afac1
Two articles covering retention policies for extension-owned tables, the gap that lets high-volume log tables grow unbounded: - register-owned-log-tables-for-retention-policies: an extension's own log tables must be added to the allowed-tables list from install AND upgrade code, guarded by IsAllowedTable plus an upgrade tag, with a mandatory minimum retention where audit needs one. - ship-a-default-retention-policy-setup: registration only makes a table selectable; nothing is deleted until a Retention Policy Setup record exists, so ship one (disabled by default) as the platform's own Retention Policy Installer does. Each ships good/bad AL samples. Claims verified against the BC admin docs and the Retention Policy module in microsoft/BCApps. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011gvTjm746MtJEVWeRTbG46
18 lines
726 B
AL
18 lines
726 B
AL
codeunit 50565 "Contoso Reten. Pol. Register"
|
|
{
|
|
Subtype = Install;
|
|
Access = Internal;
|
|
|
|
// The table becomes selectable on the Retention Policies page and nothing
|
|
// else happens: no Retention Policy Setup record is created, so no period
|
|
// is proposed and no data is ever deleted. The log table keeps growing
|
|
// until someone notices the tenant's storage consumption.
|
|
trigger OnInstallAppPerCompany()
|
|
var
|
|
ContosoActivityLog: Record "Contoso Activity Log";
|
|
RetenPolAllowedTables: Codeunit "Reten. Pol. Allowed Tables";
|
|
begin
|
|
RetenPolAllowedTables.AddAllowedTable(
|
|
Database::"Contoso Activity Log", ContosoActivityLog.FieldNo(SystemCreatedAt));
|
|
end;
|
|
}
|