Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 14:46:55 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 4
bcquality/microsoft/knowledge/data-modeling/insert-only-transfer-may-rely-on-caller-cleanup.md
Wenjie Fan 35a7e72f12
knowledge: three false-positive guards from BCApps PR 10277, 10278 and 10346 (#146) 
data-modeling: add insert-only-transfer-may-rely-on-caller-cleanup. A filter-and-insert transfer routine was reported for stale rows and duplicate keys even though the field OnValidate trigger calls a sibling cleanup procedure that clears the same range immediately before it. Deciding this requires reading the caller, so the article asks reviewers to trace call sites and keeps uncleared or mismatched-filter paths reportable.

appsource: scope two-level-namespace-replaces-object-affix-not-extension-member-affix to apps that actually configure a mandatory affix. AS0011 only runs when AppSourceCop is enabled with a mandatory affix; a first-party in-box app that ships no such configuration is not subject to it. The member-affix requirement itself is unchanged for apps that do configure one.

testing: allow permission-tests-must-lower-the-execution-context to accept a composed role. The article demanded the exact permission set under test be assigned directly, so a test that lowered permissions through a role including that set and then asserted WritePermission was false was reported as a coverage gap. What matters is the effective context plus a boundary assertion, not which object the test names.

Co-authored-by: wenjiefan <wenjiefan@microsoft.com>
2026-09-02 11:25:19 +02:00

2.2 KiB
Raw Blame History

bc-version domain keywords technologies countries application-area
all
data-modeling
transfer
cleanup
deleteall
onvalidate
caller
stale-rows
false-positive
al
w1
all

An insert-only transfer routine may rely on cleanup its caller already performed

Description

A routine that copies rows from a template table into a target table — a TransferX procedure filling comment, dimension, or attribute lines from a standard-task or template record — is frequently written as filter-and-insert with no DeleteAll of its own. That is not automatically a stale-row or duplicate-primary-key defect. In the common AL shape, the field's OnValidate trigger first calls a sibling cleanup procedure that clears the same filtered range, then calls the transfer. By the time Insert runs, the target range is guaranteed empty, so the transfer has nothing to clean up and adding a second DeleteAll inside it would be redundant.

Deciding whether a missing cleanup is real therefore requires reading the caller, not just the routine in the diff. The relevant question is whether every path that reaches the transfer clears the target range first — not whether the transfer clears it itself.

Best Practice

Before reporting a transfer or copy routine for missing cleanup, trace its call sites. If the callers in scope invoke a cleanup procedure that clears the same filtered range immediately beforehand — typically in the same OnValidate trigger or the same routine — the insert-only transfer is correct and must not be flagged for stale rows, duplicate keys, or a missing DeleteAll. Raise the finding only when a reachable call path inserts into a range that was not cleared, or when the cleanup filters a different range than the insert writes to.

Anti Pattern

Reporting an insert-only transfer as a stale-row or duplicate-key risk on the strength of the routine body alone, when the trigger that calls it already ran the cleanup. The mirror-image mistake is waving through a transfer whose caller clears a different filter range than the one the transfer inserts into, or one reachable from a path with no cleanup at all — those are genuine defects.