- Introduced `al-test-writer` to generate AL test codeunits for production objects based on TDD principles. - Added `al-userguide-test-writer` to create test codeunits from user guide steps, mapping actions and assertions. - Implemented `bc-extension-test-guide` to generate a comprehensive TEST_GUIDE.md for Business Central extensions, covering various categories. - Created `bc-webclient-runner` to automate UI testing of the Business Central web client, capturing screenshots and asserting UI states. - Developed `page-scripting-e2e` to produce a recording plan for Page Scripting, ensuring a structured approach to browser-level testing.
7.2 KiB
| kind | id | version | title | description | inputs | outputs | bc-version | technologies | countries | application-area | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| action-skill | al-permission-set-auditor | 1 | AL permission set audit | Audits that every object an AL extension defines appears in a permission set with appropriate scope, and emits a findings report. |
|
|
|
|
|
|
AL permission set audit
Compares the objects a Business Central AL extension defines against the entries in its permission set files and reports every gap. This catches the silent-but-fatal class of bug where a new table ships without permission, the install succeeds in the developer SUPER sandbox, and tenants hit "Permission denied" on first use. It is also the single most common cause of AppSource rejection (the AS0029 family). This skill sources from the security domain and cites curated permission-set guidance where present, otherwise it emits agent findings within its security and permissioning domain. This is a leaf action skill: it invokes no sub-skills.
An orchestrator invokes this skill with an object-list, a repository, or a pr-diff. It produces a single JSON document conforming to the DO output contract.
Source
Read the BCQuality knowledge index once (the knowledge-index.json Entry's preparation step regenerates over the live, already-filtered clone). Take the index entries whose domain is security as the citable candidate set across every enabled layer, weighted toward permission-set guidance: minimal-grant, avoiding wildcard grants, indirect and inherent permissions. A scope that grants more than the usage warrants maps onto a curated rule and MUST cite it rather than be paraphrased. Do not open individual article files at this step; open an article's full body only once it enters the Worklist below. The object-to-permission coverage gap itself (a defined object with no permission entry, a table line with no tabledata line) is not encoded in the corpus; for those concrete defects, emit an agent finding within this skill's security and permissioning domain (see Action).
Relevance
Apply the frontmatter matching rules defined in READ against the task context:
bc-version: the target BC version from the branchapp.json, orunknownif unavailable.technologies:[al].countries: the consuming app's declared countries, orunknown.application-area: the application areas of the changed objects, orunknown.
Discard files that are not applicable. Retain conditionally applicable files (any dimension unknown) only when configuration permits; findings derived from them have confidence no higher than medium, and the finding message names the unknown dimensions.
Worklist
Build the object-to-permission map and narrow to the gaps:
- Walk the supplied
object-list(or the source underrepository) to build the set of(ObjectType, ObjectName)declarations. When apr-diffis the input, narrow to the objects the diff adds or renames. - Walk every
*.PermissionSet.althe extension defines to build the set of granted entries. - For each defined object, the gap set is: no matching permission entry anywhere; a
tableentry with no correspondingtabledataentry; atabledatascope wider than the object's actual usage; a public codeunit with callable procedures and no entry, or anAccess = Internalcodeunit with a redundant entry; an orphan entry that matches no defined object; a permission set with an empty or non-meaningfulCaption; a permission set whose own ID falls outside theapp.jsonid range.
A curated security permission-set file enters the worklist when its keywords intersect these tokens (for example permission-set, tabledata, wildcard, minimal-grant). Read its full body only after it makes the worklist. Resolve layer-precedence conflicts per READ and record dropped files in suppressed.
Action
For each gap, emit a finding.
When the gap is an over-broad or wildcard scope that maps onto a curated security rule (a tabledata grant wider than the usage, a wildcard grant), emit a knowledge-backed finding citing that file: id equal to the file path, the file as primary reference, severity up to blocker only when the file states a platform-level guarantee otherwise major, confidence high for an unambiguous match.
When the gap is a coverage defect with no curated rule (a defined object missing from every permission set, a table entry with no tabledata line, an orphan entry, a missing or noise Caption, a permission set out of the id range), emit an agent finding within this skill's security and permissioning domain: references: [], id slug prefixed agent: (for example agent:object-missing-from-permission-set or agent:table-without-tabledata), confidence capped at medium, severity capped at minor, and a self-contained message naming the object, the permission set, and the exact entry to add. Where the impact would normally gate (a new table absent from every permission set, which AppSource rejects), keep severity at minor but say so plainly in the message and note the concern should be promoted to a knowledge-backed rule before it can gate. Hold every candidate to the precision bar in skills/do.md: steelman that the object is intentionally not granted (a pure framework object behind Access = Internal) before emitting, and omit when in doubt. Before emitting any agent candidate, check the worklisted knowledge for a match and upgrade it to a knowledge-backed finding if one exists.
Set suggested-code when the fix is the exact permission line to add (for example tabledata "Event Registration" = RIMD;); otherwise set suggested-code-omission-reason. Group repeated instances of one concern into a single finding rather than many near-identical ones.
Outcome selection: completed when every object was evaluated (including an empty findings); no-knowledge when no curated knowledge survived and no agent finding was raised; not-applicable when the task has no objects or permission sets to compare; partial or failed per the DO contract with outcome-reason.
Output
Output conforms to the DO output contract. A populated example:
{
"skill": { "id": "al-permission-set-auditor", "version": 1 },
"outcome": "completed",
"summary": {
"counts": { "blocker": 0, "major": 0, "minor": 1, "info": 0 },
"coverage": { "worklist-size": 47, "items-evaluated": 47 }
},
"findings": [
{
"id": "agent:table-without-tabledata",
"severity": "minor",
"message": "Table 50100 Event Registration is granted as a table entry in permission set MyExt All but has no tabledata entry, so the metadata is exposed but read and write are denied. Add the tabledata line beneath the existing table line. Impact would normally be major because AppSourceCop AS0029 rejects this; emitted as minor because no curated rule backs it. This concern should be promoted to a knowledge-backed rule before it can gate.",
"location": {
"file": "src/MyExt.PermissionSet.al",
"line": 12
},
"references": [],
"confidence": "medium",
"suggested-code": " tabledata \"Event Registration\" = RIMD;"
}
],
"suppressed": []
}