mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-08-08 18:31:36 +01:00
Add CMFRT coding standards documentation and examples
- Introduced guidelines for "one codeunit one global function" architecture to enforce single responsibility in AL code. - Added best practices and anti-patterns for adding parameters via overloads to maintain backward compatibility. - Documented the importance of never deleting members in AL and always marking them as obsolete. - Established the requirement for OnBefore and OnAfter integration events for global procedures to enhance extensibility. - Defined naming conventions for CMFRT objects, including prefixes and object ID ranges to avoid conflicts. - Implemented patterns for case statements to ensure all cases are handled, including the necessity of an else clause. - Introduced the interface injection pattern to allow pluggable operations in table-level code. - Recommended using Confirm Management for user confirmations to improve testability. - Established a three-permission set pattern for security to ensure proper access control. - Created a review skill for CMFRT AL standards to automate compliance checks against established guidelines.
This commit is contained in:
parent
4119417ce4
commit
c72c0ad685
35 changed files with 866 additions and 0 deletions
26
custom/knowledge/patterns/cmfrt-use-confirmmanagement.md
Normal file
26
custom/knowledge/patterns/cmfrt-use-confirmmanagement.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
bc-version: [all]
|
||||
domain: patterns
|
||||
keywords: [confirm, confirmmanagement, dialog, user-confirmation, test, automation, testability]
|
||||
technologies: [al]
|
||||
countries: [w1]
|
||||
application-area: [all]
|
||||
---
|
||||
|
||||
# CMFRT use ConfirmManagement instead of Confirm
|
||||
|
||||
## Description
|
||||
|
||||
CMFRT AL code must use the `"Confirm Management"` codeunit to prompt the user for confirmation instead of calling the `Confirm` built-in function directly. `"Confirm Management"` wraps `Confirm` and resolves confirmation dialogs without displaying UI during automated test runs, making test behaviour deterministic. The `Confirm` built-in always renders a modal dialog regardless of execution context, which causes automated tests to hang waiting for user input.
|
||||
|
||||
## Best Practice
|
||||
|
||||
Declare `ConfirmManagement: Codeunit "Confirm Management";` as a local variable and call `ConfirmManagement.GetResponseOrDefault(QuestionLbl, true)`. The codeunit suppresses the dialog automatically in test context. Use a `Label` for the question text so it is translatable.
|
||||
|
||||
See sample: `cmfrt-use-confirmmanagement.good.al`.
|
||||
|
||||
## Anti Pattern
|
||||
|
||||
Calling `if Confirm(QuestionText, true) then` directly. Direct `Confirm` calls are not interceptable by the test framework: the modal dialog appears during automated test runs, causing the test to stall indefinitely or fail with a UI-interaction error. Tests that hit a `Confirm` call cannot be run in a CI pipeline without manual intervention.
|
||||
|
||||
See sample: `cmfrt-use-confirmmanagement.bad.al`.
|
||||
Loading…
Add table
Add a link
Reference in a new issue