[Subscription Billing] Page 8002 "Extend Contract" — move key variables to protected var and add setters for PageExtension automation

[Patrik Müller (pamura1977)]

What & why

Page 8002 "Extend Contract" only exposed a limited set of variables in its protected var section, leaving several variables that partner extensions need to read or write in the global (unprotected) var block. This blocked automation scenarios on top of the standard "Extend Contract" flow without cloning the entire page.

This change moves seven variables (CustomerContractNo, VendorContractNo, SubscriptionDescription, ItemDescription, UnitPrice, UnitCostLCY, ProvisionStartDate) to protected var, and adds two new setter procedures (SetVendorContractParameters(), SetItemParameters()) following the existing SetUsageBasedParameters() pattern, so that a PageExtension can supply these values before OnOpenPage runs its validation chain, ensuring dependent fields (item description, unit price/cost, subscription packages) are populated correctly instead of appearing empty.

Linked work

Fixes #8856

Fixes AB#646374

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app locally with no new analyzer warnings.

What I tested and the outcome

• Compiled the "Subscription Billing" app locally (AL: Package) against a BC 29 Early Access Preview sandbox (29.0.52714.0); build succeeded ("Success: The package is created"). The only compiler warnings (AL0920, in RecentItemPrice/CalculationBaseByPerc/PriceByPercent codeunits) are pre-existing in main and unrelated to this change.
• Given the small, additive scope of this change (visibility change + two new setters following an existing, already-used pattern), I did not further test this in a Business Central instance.

Risk & compatibility

None expected. All changes are additive:

• Moving variables from var to protected var does not change any existing behavior for the base app or existing callers. It only widens accessibility for PageExtensions.
• The two new setter procedures are new public entry points; no existing procedure signature is modified.
• The one behavioral addition (re-applying VariantCodeParam at the end of OnOpenPage) is guarded by if VariantCodeParam <> '', so existing manual-entry behavior (no parameters supplied) is unchanged.

[Patrik Müller (pamura1977)]

@microsoft-github-policy-service agree company="redPoint AG"

[alexei-dobriansky]

Agentic PR Review - Round 1

Recommendation: Accept

What this PR does

This PR widens the extension surface of page 8002 Extend Contract. It moves existing page state to protected var and adds two parameter setters so automation can provide item, quantity, variant, and vendor contract values before OnOpenPage runs.

The change is coherent for this extensibility request. The new setters use the same staged-parameter pattern as the existing page entry points, and SetGlobalsFromParameters() applies those values before the existing validation chain. Re-applying VariantCodeParam after ValidateItemNo() is also needed because that validation clears VariantCode for normal manual entry. The moved variables are already page state used by editable or calculated fields, so making them protected does not bypass ExtendContract() checks before the contract extension is created.

Suggestions

None.

Risk assessment and necessity

Risk: The main risk is compatibility from widening the page extension surface. This is additive: no existing signatures are changed, and the final ExtendContract() path still checks contract records, item existence, subscription packages, and provision start date before it creates data. I did not find an AB# work item in the PR, so the scenario was assessed from GitHub issue #8856 and the diff.

Necessity: The request is valid for partner automation. Without these setters and protected variables, a PageExtension can set values only after the base page OnOpenPage logic has run, so dependent state such as packages, cost, price, and contract records can be stale or empty. A functional test is not a hard requirement here because the change is an additive extensibility surface and is mostly compile-time access plus existing page validation.

---

[AI-PR-REVIEW] version=1 system=github pr=9715 round=1 by=alexei-dobriansky at=2026-08-03T10:18:50Z lastSha=b45deeedc413b2ca64fab5d0941bb4d72ec1307a suggestions=

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Agent}$

In OnOpenPage, VariantCode := VariantCodeParam (lines 306-307) is applied unconditionally whenever VariantCodeParam is non-empty, but it runs after ValidateItemNo(), which resets VariantCode to '' whenever ItemNo is empty/invalid (line 418-419). If a caller invokes SetItemParameters with an invalid or empty ItemNo but a non-empty VariantCode (e.g. NewItemNo not passed, or an item that doesn't exist), the page ends up displaying/holding a VariantCode with no corresponding ItemNo, undoing the reset ValidateItemNo() just performed. This inconsistent state can flow into ExtendContract -> InsertFromItemNoAndCustomerContract with a variant code but a blank item number. Recommend guarding the assignment on ItemNo being non-empty, mirroring ValidateItemNo's own condition.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

        if (ItemNo <> '') and (VariantCodeParam <> '') then
            VariantCode := VariantCodeParam;

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

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Agent}$

The two new parameter-setter procedures added in this diff, SetVendorContractParameters (line 678) and SetItemParameters (line 684), are declared as plain procedure (public), while the page's pre-existing, analogous parameter setters SetParameters (line 641) and SetUsageBasedParameters (line 672) are declared internal procedure. These setters exist solely to let sibling code in the same app pass values into this page before it opens (a page-internal wiring pattern), so widening two of the four to public unnecessarily enlarges the page's external API surface and is inconsistent with the established convention on this same object. Recommend declaring both new procedures as internal procedure to match the existing setters unless external (cross-extension) callers are an explicit, intended requirement.

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

[Patrik Müller (pamura1977)]

SetVendorContractParameters and SetItemParameters, the two new setter procedures added in this PR, need to stay public. A PageExtension from our app has to call them before OnOpenPage runs, in order to populate the protected var fields requested in issue #8856.