Add 18 more community AL/BC patterns across appsource, data-modeling, error-handling, security, style, testing, ui, upgrade, and web-services

Second contribution from CURABIS ApS, generalized from patterns observed across real AppSource/PTE development. Cross-checked against the current microsoft/knowledge corpus before opening; several originally-drafted candidates were dropped as duplicates of existing files.

microsoft/knowledge/upgrade/upgrade-tag-logic-must-not-nest-deeply.bad.al

@@ -0,0 +1,14 @@
+local procedure UpgradeCustomerDiscountField()
+begin
+    if not UpgradeTag.HasUpgradeTag(GetCustomerDiscountFieldTag()) then begin
+        if Customer.FindSet() then begin
+            repeat
+                if Customer."Discount %" = 0 then begin
+                    if Customer."Customer Posting Group" <> '' then
+                        Customer."Discount %" := 5;
+                end;
+            until Customer.Next() = 0;
+        end;
+        UpgradeTag.SetUpgradeTag(GetCustomerDiscountFieldTag());
+    end;
+end;

microsoft/knowledge/upgrade/upgrade-tag-logic-must-not-nest-deeply.good.al

@@ -0,0 +1,14 @@
+local procedure UpgradeCustomerDiscountField()
+begin
+    if UpgradeTag.HasUpgradeTag(GetCustomerDiscountFieldTag()) then
+        exit;
+
+    Customer.SetLoadFields("Discount %");
+    if Customer.FindSet() then
+        repeat
+            Customer."Discount %" := 5;
+            Customer.Modify();
+        until Customer.Next() = 0;
+
+    UpgradeTag.SetUpgradeTag(GetCustomerDiscountFieldTag());
+end;

microsoft/knowledge/upgrade/upgrade-tag-logic-must-not-nest-deeply.md

@@ -0,0 +1,28 @@
+---
+bc-version: [all]
+domain: upgrade
+keywords: [upgrade-tag, nesting, complexity, upgrade-per-company, upgrade-per-database]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+---
+
+# Keep upgrade tag conditional logic to at most two levels of nesting
+
+## Description
+
+The conditional logic that gates upgrade code behind an upgrade tag should be at most two levels deep: check the tag, exit if already applied, otherwise run the upgrade step. Deeper nesting — tag checks inside tag checks, or a tag check combined with multi-branch business-data conditions — signals that the upgrade step is trying to do more than one thing, or that it is reconstructing decision logic that belongs in the tag structure itself (one tag per distinct upgrade step), not in nested `if` statements inside a single step.
+
+Upgrade code runs unattended, once, against production data with no chance to interactively debug a wrong branch. The cost of a nesting-driven mistake here is much higher than in ordinary application code, which is why the ceiling is lower than general AL style would otherwise allow.
+
+## Best Practice
+
+One tag check, one exit, one upgrade action — two levels deep at most.
+
+See sample: `upgrade-tag-logic-must-not-nest-deeply.good.al`.
+
+## Anti Pattern
+
+Nesting the tag check, a record loop, and a multi-branch business condition inside one procedure. Split the buried business condition into its own, separately tagged upgrade step instead.
+
+See sample: `upgrade-tag-logic-must-not-nest-deeply.bad.al`.