mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 22:56:55 +01:00

Paulius Urbanas 5149da25ba Add StrongPoint custom knowledge layer

Eight organization rules in custom/knowledge, each overriding or
supplementing the Microsoft layer for StrongPoint repositories:

- style/spu-prefix-on-objects-and-extension-members
- style/cyclomatic-complexity-is-not-a-gate-in-sp-repos (LC0010 = Info)
- ui/keep-tooltips-on-sp-page-fields (AA0218 = Error, LC0064 off;
  overrides microsoft ui/bound-page-field-inherits-source-field-tooltip)
- data-modeling/sp-field-names-fit-30-chars-with-prefix (AL0468 = Error)
- events/change-ls-central-behaviour-through-its-events
- web-services/device-io-goes-through-sp-device-manager
- appsource/sp-id-ranges-are-not-checked-by-as0084 (AS0084 = None)
- upgrade/sp-released-ids-never-change

Sources: sp.ruleset.json across SP repositories, SPUFBUpgrade pattern in
SP-LSC-Fiscal-Printing, observed LS Central and Device Manager usage.
Verified: all eight are indexed by Build-KnowledgeIndex.ps1, and a review
of a probe app applied the ToolTip rule as major and suppressed the
Microsoft article by layer precedence.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

2026-09-25 13:50:52 +03:00

1.9 KiB

Raw Blame History

bc-version

domain

keywords

technologies

countries

application-area

all

upgrade

object-id

field-id

renumber

breaking-change

upgrade-codeunit

upgrade-tag

pipeline

all

Released object and field IDs never change in StrongPoint apps

Description

Once any release of an SP app exists, the AL-Go pipeline rejects a change to an existing object ID or table field ID. Changing an ID is a schema break: installed tenants would lose the data in the old object or field. When data really has to move — a field replaced by a new one, a table split — the old element stays (marked obsolete), a new element gets a new ID, and an upgrade codeunit copies the data.

Best Practice

Never renumber released objects or fields, even to tidy a range. For a data move, add the new object or field, mark the old one ObsoleteState = Pending, and migrate in a Subtype = Upgrade codeunit's OnUpgradePerCompany, one upgrade tag per step (HasUpgradeTag / SetUpgradeTag), with every tag registered in an OnGetPerCompanyUpgradeTags subscriber and matching install-code handling for new installs. SPU FB Upgrade in SP-LSC-Fiscal-Printing is the reference implementation. Report a changed released ID as blocker.

Anti Pattern

Editing the number in table 70760600 or field(12; ...) of a released object, deleting a released field instead of obsoleting it, or migrating data without an upgrade tag so it re-runs on every upgrade.

References

StrongPoint policy: workspace CLAUDE.md ("Breaking change rule", "Upgrade Codeunits"); reference code SP-LSC-Fiscal-Printing/.../SPUFBUpgrade.Codeunit.al. Related shared rules: microsoft/knowledge/upgrade/use-upgrade-tags-not-version-checks.md, microsoft/knowledge/upgrade/register-upgrade-tags-with-subscribers.md, microsoft/knowledge/breaking-changes/obsolete-table-fields-instead-of-deleting-them.md.

1.9 KiB Raw Blame History