The Permissions property on codeunit objects should use lowercase r i m d` only

[rvanbekkum]

From discussion on Yammer (Link: https://engage.cloud.microsoft/main/org/microsoft.com/threads/eyJfdHlwZSI6IlRocmVhZCIsImlkIjoiMzkyNjI0NTIxMzc3MzgyNCJ9?trk_copy_link=V2)

Question: Difference between upper- and lowercase tabledata permissions in Codeunits? (M. Felix)

Can anyone enlighten me to the difference between upper- and lowercase permissions defined in codeunits?

Looking at the base app almost all permissions within codeunits are written in lowercase, for example in Sales-Post. Dimension Management (408) on the other hand uses mixed upper and lowercase for different tabledata.

I wrote a small extension app for testing it, and in a docker container I could see no difference at all between the two. A user with indirect permissions was able to write to the table regardless of upper- or lowercase, while a user without permissions was not able to do so in either case.

Thanks in advance!

Best Answer: (@pri-kise)

there's no difference at all. I would recommend to use lowercase here, that anyone don't get wrong expectations.

you can only enable a user with indirect permission to perfom an action on a table when the permissions are definied on the permissions property.

the uppercase is only relevant in permission set objects where you define if a user with this permission set will have direct or inderct permissions to an ojbect

or

on the inherentpermissions property that you can add to procedures.

Additional Answer (M. Nielsen)

Your test result matches how it actually works: at runtime there's no practical difference between upper- and lowercase in the Permissions property on a codeunit.

The documented intent (Permissions property docs) is that uppercase declares direct permission and lowercase declares indirect. But the property only ever does one job: when the object is in the call stack, it supplies the "object side" of the indirect-permission handshake. The two conditions that matter are:

The user has at least indirect permission on the tabledata (from a permission set or license). If they have none, the property doesn't help — which is why your no-permission user failed in both cases.
The object declares the operation in Permissions at all. Whether it's M or m is irrelevant to the check — which is why your indirect user succeeded in both cases.
Uppercase can't elevate anything beyond that either: on license-restricted tables, declaring direct permission in the property doesn't grant access the license withholds, so the direct/indirect distinction in this property effectively collapses. Stefan Maron demonstrates exactly this and notes that capital letters "don't actually elevate anything" on license-restricted tables.

The mixed casing in the base app (lowercase in Sales-Post, mixed in Dimension Management 408) is historical inconsistency from the C/SIDE-to-AL conversion and years of edits by different teams — not intentional semantics.

Where case does matter is in permissionset objects: there RIMD vs rimd determines whether the user gets direct or indirect permission, and that's a real behavioral difference.

One caveat on your test setup: a Docker container with a developer license doesn't enforce license-level indirect restrictions the way a cloud sandbox does, so code can pass locally and fail at a customer. Since your no-permission user was correctly blocked, your permission-set enforcement was working, but for license-restricted tables (posted documents, ledger entries) verify in a cloud sandbox or with TestPermissions = Restrictive in AL tests.

Sources:

• Permissions property — Microsoft Learn
• Indirect Permissions in Business Central — Stefan Maron
• What's the story with indirect permissions — Erik Hougaard

So, I think it could be good to have a code analyzer rule that checks that lower-case r, m, i, d is used in the Permissions property on codeunit objects (and probably also the other object types that support the property, except for permissionset and permissionsetextension objects where it has a different meaning).

[Arthurvdv]

We're picking this up as a new FormattingCop rule: FC0006 PermissionValuesShouldBeLowercase.

Before implementation lands, two scope questions for anyone following this discussion:

1. Codeunit objects only, or all objects with a Permissions property?

Verified against the compiler internals (PropertyInfoLookup), the Permissions property is supported on these object types:

• codeunit
• table
• page
• report
• requestpage (in reports and xmlports)
• xmlport
• query

Extension objects (tableextension, pageextension, reportextension) don't support the property at all.

The case-insensitivity argument applies identically to all seven, so the current plan is to cover all of them. Explicitly excluded, since casing carries real meaning there:

• permissionset / permissionsetextension objects (uppercase = direct, lowercase = indirect)
• the InherentPermissions property

Any reason to limit the rule to codeunit objects only?

2. Should lowercase x be enforced next to rimd?

Non-tabledata entries in the Permissions property (e.g. codeunit "Sales-Post" = X) only accept the execute permission X/x, and the parser uppercases before validating, so casing is free-form there too. For consistency the plan is to also flag uppercase X and suggest lowercase x. Counterpoint: Microsoft's docs examples use uppercase X for these entries, so this could generate more findings against documented convention.

Current plan: enforce lowercase everywhere (r, i, m, d, x), one Info-severity diagnostic per Permissions property, with a code action that lowercases all values. Feedback welcome.

Generated with Claude Fable 5

[rvanbekkum]

1. Yes, correct, cover these object types, not just codeunit objects.
2. Yes, I think it should apply for execute permission.