Permission declarations should be sorted by object type and name

Properties

FC0004 Info Style Code Fix Ignore Obsolete

A consistent order of Permissions property entries is not cosmetic. It directly reduces merge conflicts in source control.

When two developers (or agents) add a permission entry to the end of an unsorted list, that change touches the same line range and produces a conflict almost every time. In a sorted list, each entry lands at a deterministic position. Two additions to a sorted list are unlikely to collide unless they happen to be adjacent. The result is fewer unexpected conflicts and less friction during code review and merging.

This matters most for permissionset objects, which routinely contain dozens of entries. But it applies equally to the Permissions property on codeunits, reports, queries, and xmlports.

Sort order

FC0004 enforces the following order. The code fix reorders entries to match (see Code fix ):

table and tabledata entries come first, interleaved and sorted by object name. When a table and a tabledata entry share a name, table comes first.
The remaining entries follow in this fixed type order: codeunit, page, query, report, xmlport, each type sorted by object name.
Object names compare naturally, case-insensitively and ignoring spaces: Item 2 comes before Item 10, and "Post. Appr. Setup" comes before "Post Inv. Setup" (compared as Post.Appr.Setup vs PostInv.Setup).
Entries inside #region … #endregion blocks are sorted within their block; blocks keep their position, and entries that follow a block are moved above it (a block’s own entries are listed before its nested blocks).
Lists that contain other preprocessor directives (#if, #pragma, …) or unbalanced #region directives are not checked.

system permissions are treated as table-type entries and sorted by name inside the table group.

Breaking change. Earlier versions of FC0004 sorted alphabetically by type keyword (codeunit, page, report, tabledata, …) and compared names ordinally. Code that satisfied the old rule may now be reported; the code fix reorders it.

This sort order is compatible with the Sort Permissions command of the AZ AL Dev Tools extension. Code sorted by either tool satisfies the rule.

Example

The following permissionset declares entries in arbitrary order:

permissionset 50100 "Sales Permissions"
{
    Assignable = true;
    Access = Public;

    Permissions = codeunit "Sales-Post" = X,
                  tabledata "Sales Header" = R,
                  page "Sales Order" = X,
                  tabledata Customer = R; // Permission declarations should be sorted by object type and name [FC0004]
}

Table entries first, sorted by name, then the other types in their fixed order:

permissionset 50100 "Sales Permissions"
{
    Assignable = true;
    Access = Public;

    Permissions = tabledata Customer = R,
                  tabledata "Sales Header" = R,
                  codeunit "Sales-Post" = X,
                  page "Sales Order" = X;
}

Code fix

The ALCops: Sort permission declarations code fix reorders the entries in place. Indentation, comments and #region blocks keep their layout; only the entries move. When the original declaration is on a single line, the fix converts it to multi-line format for readability.

Permission declarations should be sorted by object type and name

Sort order

Example

Code fix

See also