mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-06 23:26:55 +01:00
Addresses microsoft/BCQuality#175 review feedback: - Extend al-data-modeling-review's entry gate/relevance scope and token list to recognize document actions, Navigate subscribers, Report Selection registration, price-calculation/price-source extensibility, TransferFields posting-cascade mirroring, and barcode font-provider usage - previously excluded before any worklist cue could run. - Fix document-print-and-email-actions-call-report-selections-directly: permit the legitimate stateless DocumentSendingProfile.TrySendToPrinter/ TrySendToEMail path; rework the bad fixture to load a configured profile instead of demonstrating a trivial blank-record no-op. - Fix extend-report-selection-usage-for-new-document-types: scope to the applicable single counterparty (ReportSelectionHandlerCZZ partitions strictly; only genuinely two-sided usages like Compensation need both), and add the page-facing usage-enum map/validate events alongside the filter-event subscription for full Document Layouts support. - Fix a stale field-citation in custom-document-dispatch-must-not-bypass- report-selections (Custom Report Layout Code is field 7, not part of the 19-26 email-configuration range). - Add deterministic positive/clean evaluation coverage (review-fixtures.json additionalArticles + Test-ReviewFixtures.ps1 support) so all 9 new good/bad pairs are actually exercised, not just present. - Add 4 new patterns: activate-new-price-calculation-handler-via- onfindsupportedsetup, extend-price-source-type-must-sync-document- subset-enum, new-price-source-must-add-candidate-and-trigger- recalculation, report-barcodes-must-use-barcode-module-and-production- font-name. All claims verified against live microsoft/BCApps source and Microsoft Learn. Validators: frontmatter 0/0, review-fixtures 52 cases/17 domains PASSED, knowledge-index 309 articles PASSED. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
64 lines
2.9 KiB
Markdown
64 lines
2.9 KiB
Markdown
---
|
||
bc-version: [all]
|
||
domain: data-modeling
|
||
keywords: [report-selections, document-layouts, custom-report-layout, email-attachment, bespoke-dispatch]
|
||
technologies: [al]
|
||
countries: [w1]
|
||
application-area: [all]
|
||
---
|
||
|
||
# Custom document dispatch must not bypass Report Selections
|
||
|
||
## Description
|
||
|
||
A codeunit that hardcodes which report to run (`Report.RunModal(MyReportId, ...)`)
|
||
and builds its own email directly, instead of registering the document
|
||
through `table 77 "Report Selections"` and calling its own
|
||
Print/Email procedures, works for the one case it was written for — and
|
||
loses everything the platform's registry provides for free. `Report
|
||
Selections` carries its own attachment/email-body configuration per usage
|
||
(`"Use for Email Attachment"`, `"Use for Email Body"`, `"Email Body Layout
|
||
Code"`, `"Email Body Layout Type"`), plus a separate per-usage layout
|
||
override, `"Custom Report Layout Code"`, and
|
||
`table 9657 "Custom Report Selection"` (the "Document Layouts" page on the
|
||
Customer/Vendor card) lets one specific account override the report or
|
||
layout without touching code at all. None of that exists for a document
|
||
whose dispatch was hand-rolled: there is no registry row to point
|
||
"Document Layouts" at, so an admin who goes looking for where to change
|
||
this document's layout — the same place they'd look for every other
|
||
document in the system — finds nothing, because the document was never
|
||
registered there.
|
||
|
||
## Best Practice
|
||
|
||
Register the document under a `Report Selection Usage` value (see
|
||
`extend-report-selection-usage-for-new-document-types.md`) and dispatch
|
||
through `Report Selections`' own Print/Email procedures (see
|
||
`document-print-and-email-actions-call-report-selections-directly.md`),
|
||
even when the surrounding business logic — which counterparty to use,
|
||
what validation must pass before sending — is genuinely specific to the
|
||
document. Custom logic belongs around the call to `Report Selections`,
|
||
not instead of it.
|
||
|
||
See sample: `custom-document-dispatch-must-not-bypass-report-selections.good.al`.
|
||
|
||
## Anti Pattern
|
||
|
||
A codeunit that runs a hardcoded report ID and builds its own email
|
||
message directly, with no `Report Selections` row backing it. It works for
|
||
the default case, but the report/layout cannot be changed per account
|
||
without a code change and a new release, and the document is invisible to
|
||
"Document Layouts" — the standard place every other document's
|
||
distribution is configured.
|
||
|
||
See sample: `custom-document-dispatch-must-not-bypass-report-selections.bad.al`.
|
||
|
||
## Source
|
||
|
||
BCApps `ReportSelections.Table.al` (table 77 — field 7,
|
||
`"Custom Report Layout Code"`; fields 19–26 for email attachment/body
|
||
configuration; `SendEmailToCust`/`PrintWithDialogForCust` as the
|
||
registry-backed dispatch entry points) and
|
||
`CustomReportSelection.Table.al` (table 9657, the per-account override
|
||
backing the "Document Layouts" page) — both under
|
||
`src/Layers/W1/BaseApp/Foundation/Reporting/`.
|