knowledge(testing): license-entitlement failures on posted tables in a SaaS test run are environmental

[Nabil BA-MOH (NavNab)]

What

One community knowledge file (testing) with good/bad samples: a test that inserts directly into a posted or ledger table fails under a SaaS user license with Your license does not grant you the following permissions on TableData <table>: Insert, while the same test is green under a container / pipeline runner. The failure is environmental, and neither TestPermissions = Disabled nor SUPER lifts it, because it is a license-entitlement check, not a permission-set check.

Admission test

A capable LLM reading that message in a test log classifies it as a permission regression of the change under review and "fixes" it with TestPermissions = Disabled or a broader permission set — neither of which is consulted by the license check. Observed on a real suite run headless against a SaaS sandbox (al runtests): the failing codeunits were byte-identical to the pre-change baseline and green in the AL-Go pipeline. The file encodes the triage rule (compare with the baseline in the same environment first) and the durable fix (produce posted data through posting via the test library codeunits, so the fixture runs under any license).

This is the testing-side counterpart of security/do-not-grant-rights-beyond-a-users-entitlement.md — that one is about what an app may grant; this one is about how the entitlement shows up in a test run and how to read it.

Checks

• validate_frontmatter.py: 0 errors, 0 warnings. Test-KnowledgeIndex.ps1: PASSED.
• 28 lines, one concern, samples referenced by filename, ids 50542–50543 (unused in the corpus). New community/knowledge/testing/ folder (first community article in that domain).
• Test-ReviewFixtures.ps1 could not be run locally (a .NET assembly-load crash that reproduces on the untouched upstream tree — environment, not content); relying on CI for it.

[Nabil BA-MOH (NavNab)]

@microsoft-github-policy-service agree company="Asio Services"

[Jesper Schulz-Wedde (JesperSchulz)]

The article needs to distinguish an environment-specific baseline failure from a defect introduced by the change.

A direct insert into a posted/ledger table is still a bad fixture. If the diff adds that insert, the resulting SaaS entitlement failure is caused by the change and must not be dismissed as “environmental.” The baseline comparison in Best Practice is the right discriminator, but the title and Description currently state the broader conclusion unconditionally.

Please qualify the verdict: treat it as environment-limited relative to the diff only when the identical pre-change test fails in the same environment; flag a newly introduced direct insert as a test defect. Also avoid saying a generic “pipeline runner” lacks the restriction—pipelines can target SaaS too; scope that contrast to a container/development-license environment known to allow direct access.

[Jesper Schulz-Wedde (JesperSchulz)]

Two blockers remain:

• The prior scope issue is unchanged. A direct insert introduced by the diff is a real test defect; only an identical pre-change failure in the same SaaS environment is environment-limited relative to the change. Please qualify the title/Description accordingly and replace the generic “pipeline runner” contrast with a container/development-license environment known to permit direct access.
• This article is not deterministically routed by al-testing-review: its targeted list claims to cover every testing article but omits this one, while the extracted-token cues omit the license/entitlement error and the existing Init/Insert cue selects the generic fixture article. Add an explicit cue that selects this article for the SaaS license-error/direct-posted-table scenario.

The AL sample APIs and exact-tree structural validators are otherwise sound.