mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-05 22:56:55 +01:00
02e7ab15b0
Some checks are pending
Validate knowledge index / validate-index (push) Waiting to run
Validate AL review fixtures / validate-review-fixtures (push) Waiting to run
Validate skill index and report schemas / validate-contract (push) Waiting to run
Validate frontmatter and structure / validate (push) Waiting to run
* Add retention policy knowledge to the privacy domain 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 * Address review feedback on retention policy knowledge - Scope both articles to bc-version [17..] (retention policies shipped in v17). - Allowed-tables sample: add OnRefreshAllowedTables subscriber with a ForceUpdate path; the upgrade tag now gates one-time setup only. - Default-policy sample: use Retention Policy Setup.FindOrCreateRetentionPeriod instead of a hand-rolled lookup-then-insert that can collide on code. - Anti-pattern now keys on append-only tables rather than table names. - al-privacy-review: add retention-policy tokens and deterministic routing for both articles, with a bounded per-table text search for delete and registration paths. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Address second review round on retention policy knowledge - Scope both articles to bc-version [22..]: FindOrCreateRetentionPeriod first appears in the 21.1 System Application and OnRefreshAllowedTables in 22. - Reframe the default-setup article as optional guidance; registration without a setup is valid. The anti-pattern and review routing now cover only false claims that registration alone cleans up data. - Make all four samples self-contained: declare Contoso Activity Log in each, add the Retention Policy Setup permission, and guard the default setup on IsAllowedTable. - Let evaluation overrides list additionalArticles and register both retention pairs as extra privacy cases (38 cases, existing IDs unchanged). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Revert evaluation harness change for multiple articles per domain The harness intentionally evaluates one paired article per domain. Keep it as designed; how the retention pairs join privacy evaluation is left to the maintainers. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Register retention policy pairs in the privacy evaluation override Use main's articles override so both retention article pairs get positive and clean cases alongside no-pii-in-telemetry-message-string. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Jeremy Vyska <jeremy@sparebrained.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| appsource | ||
| breaking-changes | ||
| data-modeling | ||
| error-handling | ||
| events | ||
| finance | ||
| interfaces | ||
| performance | ||
| privacy | ||
| query | ||
| reporting | ||
| scm | ||
| security | ||
| style | ||
| telemetry | ||
| testing | ||
| ui | ||
| upgrade | ||
| web-services | ||
| .gitkeep | ||