mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-05 14:46:55 +01:00
Address Jesper Schulz-Wedde's review on PR #157
- release-must-update-app-version.md: reframe around AppSource's actual
strict full-version-ordering requirement; scope branching-policy
claims as team convention, not platform rule.
- pictures-must-use-media-not-blob.md: MediaSet is a collection of
independent media objects, not automatic image variants/thumbnails.
- log-writes-must-survive-rollback.{md,good.al}: StartSession's only
data channel into the new session is its Record parameter to a
TableNo-scoped codeunit; a setter called on a local instance before
starting the session populates nothing in the new session.
- exposed-objects-must-be-in-a-permission-set.md: correct the three
exposure mechanisms (Web Services config, PageType/QueryType=API,
ServiceEnabled as a method-only attribute).
- pages-must-not-contain-business-logic.md: scope to persisted
mutations and cross-entry-point rules; presentation-only
calculations and table-owned invariants are not violations.
- given-blocks-must-cover-full-precondition-chain.good.al: replace
invented LibrarySales calls with the real API
(CreateCustomer/CreateSalesOrderForCustomerNo/PostSalesDocument).
- test-feature-scenario-tags.{md,good.al}: move [SCENARIO] inside the
test procedure body to match the current BCApps corpus; keep
[FEATURE] at codeunit level per Microsoft's own documented option.
- ui-test-codeunit-naming.md: scope the _UT suffix and adjacent-ID
pairing as an explicit team convention, not a BCApps-wide standard.
- page-design-must-match-bc-page-type-conventions.md /
table-design-must-match-bc-table-type-conventions.md: Card's
single-key primary-key claim is a contextual heuristic, not a
mandatory constraint (Ship-to Address, Customer/Vendor Bank Account
are real composite-key Card pages); a Subsidiary table with its own
identity commonly gets List+Card, not Worksheet/Tabular.
- api-page-least-privilege-write-access.{md,good.al}: only page-placed
fields are ever exposed; set InsertAllowed/DeleteAllowed=false in the
good sample so a narrow field set can't still create/delete records.
- source-organized-by-feature-not-object-type.md,
test-one-when-per-test.md: scope as team/testing-design conventions,
not Microsoft platform requirements.
- upgrade-tag-logic-must-not-nest-deeply.md: add the Microsoft Learn
citation that already backs the two-level nesting limit.
- Wire the new articles into the testing/data-modeling/error-handling/
security/ui review skills' candidate-selection signals.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
parent
a4d85c3e9e
commit
0120b874b2
22 changed files with 111 additions and 58 deletions
|
|
@ -32,8 +32,14 @@ Match the page's design to its type:
|
|||
- **RoleCenter** — tailored home page for a role; named role + `Role
|
||||
Center`; links to List pages, shows Cues/Activities.
|
||||
- **Card** — view/edit one record; named table + `Card`; FastTabs only,
|
||||
first FastTab named `General`. Requires a single-field primary key — a
|
||||
multi-field key needs a List/Worksheet/Tabular page instead.
|
||||
first FastTab named `General`. A single-field primary key is typical,
|
||||
but not a hard requirement: a subsidiary table that supplements a
|
||||
master record with its own identity (parent key + own code — Ship-to
|
||||
Address, Customer/Vendor Bank Account) commonly gets its own Card page
|
||||
over a composite key too. Treat the key shape as a contextual signal,
|
||||
not a mandatory constraint — a composite-key table with no such
|
||||
supplementing relationship to a master record is the actual signal a
|
||||
List/Worksheet/Tabular page fits better.
|
||||
- **List** — view multiple records, also the lookup/drilldown surface;
|
||||
named table + `List` if read-only, or the plural table name if
|
||||
editable; primary-key fields shown left-most; `CardPageID` must point
|
||||
|
|
@ -64,10 +70,11 @@ See sample: `page-design-must-match-bc-page-type-conventions.good.al`.
|
|||
|
||||
## Anti Pattern
|
||||
|
||||
A page that mixes conventions from two types — for example, a "Card"
|
||||
page built on a table with a two-field primary key, or a "List" page
|
||||
with no `CardPageID` even though a Card page exists for the same table —
|
||||
signals a design step was skipped, not a stylistic choice. Also watch
|
||||
A page that mixes conventions from two types — for example, a "List"
|
||||
page with no `CardPageID` even though a Card page exists for the same
|
||||
table — signals a design step was skipped, not a stylistic choice. A
|
||||
Card page over a composite-key table is not automatically this anti
|
||||
pattern; check whether the table supplements a master record first. Also watch
|
||||
for: a Worksheet or List page showing primary-key fields it shouldn't (or
|
||||
hiding them when it should show them), and a page with no
|
||||
`UsageCategory` set, which makes it invisible to Tell Me search even
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue