ADded function to disable key by key type

[ehenriksen9]

What & why

Linked work

Fixes #

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome (required — be specific: scenarios, commands, screenshots for UI changes)

Risk & compatibility

[github-actions]

Could not find a linked ADO work item. Please link one by using the pattern 'AB#' followed by the relevant work item number. You may use the 'Fixes' keyword to automatically resolve the work item when the pull request is merged. E.g. 'Fixes AB#1234'

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Error\ Handling}$

Table Key Impl.Disable(IndexKey) calls Database.AlterKey(IndexKey, false) directly with no precondition validation and no success/failure signaling, unlike the sibling AlterAll local procedure it sits next to, which validates the table (skips system tables and non-Normal table types) and lets DisableAll/EnableAll return a Boolean so callers can handle unsupported input gracefully. For a key on an unsupported table (system table, non-SQL table, clustered/unique/SIFT key, etc. — all called out as unsupported in this procedure's own XML doc remarks), the new Disable will let Database.AlterKey raise an unhandled runtime error instead of failing gracefully. Recommend validating the key/table upfront (reusing the same checks as AlterAll) and exposing a Boolean or TryFunction-based result so callers get the same predictable failure contract as the existing table-level operations.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.26.4}

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Security}$

The new public Table Key.Disable(IndexKey: KeyRef) procedure is a new entry point on a public System Application codeunit that forwards a caller-supplied KeyRef straight into Table Key Impl.Disable, which calls Database.AlterKey(IndexKey, false) under Access = Internal / InherentEntitlements = X / InherentPermissions = X. Unlike this, internal access does not authorize a runtime caller; it only relies on the internal-implementation boundary, which is not a security boundary. Compounding this, the sibling table-level operations DisableAll/EnableAll in the same codeunit are marked [Scope('OnPrem')] and validate preconditions (skip system tables where TableNo > 2000000000, skip non-Normal table types) before altering any key, while the new Disable(KeyRef) has neither the [Scope('OnPrem')] attribute nor any equivalent validation. As shipped, any extension (including SaaS/AppSource extensions, since the OnPrem restriction is absent) that can obtain a KeyRef can disable an arbitrary key — including ones the documented remarks say are unsupported — without an explicit authorization or allow-list check. Align the new API with its siblings: either restrict it to OnPrem like DisableAll/EnableAll, or add the same system-table/table-type validation and explicit authorization before calling Database.AlterKey.

Knowledge:

• microsoft/knowledge/security/internal-access-is-not-a-security-boundary.md
• microsoft/knowledge/breaking-changes/choose-access-modifiers-deliberately.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.26.4}

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Breaking\ Changes}$

The new Table Key.Disable(KeyToDisable: KeyRef) procedure is declared public with no [Scope('OnPrem')] attribute, while its sibling bulk operations in the same codeunit — DisableAll and EnableAll — are both deliberately restricted with [Scope('OnPrem')]. Per BCQuality's access-modifier guidance, dropping or omitting [Scope('OnPrem')] widens the supported contract and should be a deliberate decision, not an inconsistency between sibling members of the same public surface. If single-key disable is intentionally meant to be callable from SaaS/cloud extensions (unlike the bulk variants), that asymmetry should be called out explicitly (e.g., in the XML doc remarks) and confirmed as an intended product decision; otherwise add [Scope('OnPrem')] to match DisableAll/EnableAll and avoid an unreviewed capability expansion.

Knowledge:

• microsoft/knowledge/breaking-changes/choose-access-modifiers-deliberately.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.26.4}