bcquality/custom/knowledge/security/cmfrt-three-permissionset-pattern.md
BeytullahCengiz88 c72c0ad685 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.
2026-07-02 13:12:09 +00:00

1.7 KiB

bc-version domain keywords technologies countries application-area
all
security
permissionset
permission-set
objects
read
edit
assignable
included-permission-sets
authorization
al
w1
all

CMFRT three-permission-set pattern

Description

Every CMFRT functional module must ship exactly three permission set objects: an Objects set, a Read set, and an Edit set. The Objects set lists every AL object the module owns — tables, pages, codeunits, reports, interfaces — with X (execute) access. The Read set includes the Objects set via IncludedPermissionSets and grants tabledata = R on each table. The Edit set includes the Read set and grants tabledata = IMD on each writable table. All three sets have Assignable = true. Names follow the pattern "CMFRT <ABBR> Objects", "CMFRT <ABBR> Read", and "CMFRT <ABBR> Edit".

Best Practice

Define the sets in the strict composition chain Objects ← Read ← Edit so that object access is declared once and inherited. When a new table is added to the module, update the Objects set and the tabledata entries in Read and Edit — there is no risk of the object access drifting between roles because the chain is the single source of truth for it.

See sample: cmfrt-three-permissionset-pattern.good.al.

Anti Pattern

Shipping fewer than three permission sets, omitting IncludedPermissionSets and enumerating the same object list in each set by hand, or granting RIMD access in a flat set that cannot be composed. Flat role sets that enumerate objects independently drift apart when tables are added or removed, and the resulting authorization gap is invisible until a user reports an access error in production.

See sample: cmfrt-three-permissionset-pattern.bad.al.