Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-06 07:06:54 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Fix remaining READ-convention sample links across this PR's 18 articles

Browse source 
The same plain-backtick "See sample: \`x.good.al\`." form fixed on
al-methods-limited-during-write-transactions (PR #161) turned up
repo-wide on 15 more of this PR's articles - Knowledge-Retrieval.ps1
requires the markdown-link form to associate a sample with its
article. All 16 fixed; the four local validators (frontmatter,
knowledge-index, knowledge-retrieval, review-fixtures, skill-index)
pass.
This commit is contained in:
Michael Dieringer 2026-09-21 22:30:25 +02:00
parent faa0bceb86
commit b983a6da57
16 changed files with 32 additions and 32 deletions
Download patch file Download diff file Expand all files Collapse all files

4
microsoft/knowledge/web-services/api-page-key-fields-must-be-editable-on-insert.md
View file

@ -19,10 +19,10 @@ A field listed in `ODataKeyFields` cannot have `Editable = false` when the API p
Leave every consumer-supplied key field referenced in `ODataKeyFields` without `Editable = false` on pages where `InsertAllowed = true`, so the OData layer accepts it as a writable property on POST.
See sample: `api-page-key-fields-must-be-editable-on-insert.good.al`.
See sample: [`api-page-key-fields-must-be-editable-on-insert.good.al`](api-page-key-fields-must-be-editable-on-insert.good.al).
## Anti Pattern
Marking a consumer-provided key field `Editable = false`, out of habit or for perceived safety. This silently breaks create operations with a generic `BadRequest` instead of a clear validation error.
See sample: `api-page-key-fields-must-be-editable-on-insert.bad.al`.
See sample: [`api-page-key-fields-must-be-editable-on-insert.bad.al`](api-page-key-fields-must-be-editable-on-insert.bad.al).

4
microsoft/knowledge/web-services/stored-derived-fields-must-not-be-exposed-directly.md
View file

@ -19,10 +19,10 @@ A stored field whose value is derived from other fields inside an `OnValidate` t
Recalculate the derived value in `OnAfterGetRecord` from its authoritative source — typically a FlowField — using a page-level variable, and expose that recalculated value instead of the stale stored field. Whether to also expose the source fields is a separate design decision, not a requirement of this pattern; keep the API contract scoped to what consumers actually need. If letting the consumer verify the recalculation is itself a requirement, expose every field the calculation reads, not just one of them — a derived value with two inputs needs both exposed, or the "verification" is incomplete.
See sample: `stored-derived-fields-must-not-be-exposed-directly.good.al`.
See sample: [`stored-derived-fields-must-not-be-exposed-directly.good.al`](stored-derived-fields-must-not-be-exposed-directly.good.al).
## Anti Pattern
Exposing the stored field directly via `Rec`, trusting that it was kept in sync by whichever trigger last touched it.
See sample: `stored-derived-fields-must-not-be-exposed-directly.bad.al`.
See sample: [`stored-derived-fields-must-not-be-exposed-directly.bad.al`](stored-derived-fields-must-not-be-exposed-directly.bad.al).