Extract NL customization to object extensions (TrMode)#8933
Extract NL customization to object extensions (TrMode)#8933Alexander-Ya wants to merge 23 commits into
Conversation
|
Fixes AB#640601 |
Copilot PR ReviewIteration 16 · Outcome: completed Knowledge source: https://github.com/microsoft/BCQuality@186d8a131465475c79244d994acb872cd5c0d4bf Findings by domainFindings split into Knowledge-backed (cite a BCQuality article) and Agent (the agent's own judgement, no matching BCQuality rule).
Totals: 2 knowledge-backed · 2 agent findings. Orchestrator pre-filter (2 file(s) excluded)
Findings produced by the AL review agent v1.7.3. Reply 👎 on any inline comment to flag false positives. |
The model-reported anchor for a single-line suggestion can be off by more than 8 lines (e.g. PR #8933 VendorNL Confirm() was off by 10, label rename off by 9). Widen the search window to 40 lines either side so the correct target within the same procedure is considered, while the 0.5 similarity floor and 0.1 ambiguity margin keep an unrelated look-alike from winning. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Widening the search window exposed a precision problem: a label-rename suggestion whose added Comment text echoes the field captions at the Error()/Confirm() call site would re-anchor onto the call site (PR #8933 GenJournalLineNL/GeneralLedgerSetupNL 'Text1000000/1' findings), which is worse than the original mis-anchor. Raise the similarity floor to 0.6 and use a bounded window (20). Genuine edit targets - an edited statement or a renamed declaration - score ~0.75-0.99 and re-anchor confidently (the PR #8933 Confirm() findings and the PartnerTypeMismatchMsg->Qst rename now land on the right line). Lower- confidence look-alikes stay below the floor and are suppressed, so the caller posts a manual snippet instead of a wrong auto-applicable anchor. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…Extract-NL-customization-to-object-extensions-v2
…Extract-NL-customization-to-object-extensions-v2
This comment was marked as resolved.
This comment was marked as resolved.
…Extract-NL-customization-to-object-extensions-v2
Agentic PR Review - Round 5Recommendation: Request ChangesWhat this PR doesThis PR extracts NL BaseApp Transaction Mode customization into extension objects for AB#640601. Since round 4, the author-owned AL changes are test-only: one commit fixes setup in an NL purchase document amount test, and one commit disables a W1 service-order warehouse shipment test. The NL test setup change looks like a real test fix: it enables Status of previous suggestions
New observations (commits since round 4)S6 - Do not disable unrelated W1 tests Risk assessment and necessityRisk: The main product risk is still that non-NL companies can receive NL Transaction Mode behavior through unguarded subscribers that copy or enforce Transaction Mode outside the guarded field Necessity: The extraction remains necessary for AB#640601 because it removes NL full-object customization and lowers future merge cost. The round-5 test changes are not enough to make the PR safe: the Transaction Mode scope must cover all paths, and unrelated tests should not be disabled to get the branch green.
|
The [Test] attribute on procedure PullServiceLineNoShipmentUsingUseFilter was commented out (changed to '// [Test]'), which silently removes this test case from the test run instead of deleting it or marking it Obsolete with a documented reason.The test body, assertions, and helper calls remain fully intact, indicating this was very likely a leftover debugging change rather than an intentional removal. If genuinely intentional, impact would be major (a real regression test for warehouse-shipment source filtering with no matching orders would stop running in CI without any record of why); capped to minor per agent-finding severity rules. Recommend restoring the [Test] attribute, or if the test is no longer valid, deleting it or using [Test, Disabled] equivalent tracked in an issue with a comment explaining the reason. Suggested fix (apply manually — could not be anchored as a one-click suggestion): [Test]Line mapping was unavailable, so this was posted as an issue comment. 👍 useful · ❤️ especially valuable · 👎 wrong - reply with why |
…Extract-NL-customization-to-object-extensions-v2
| Access = Internal; | ||
|
|
||
| [EventSubscriber(ObjectType::Page, Page::"Purch. Invoice Subform", 'OnAfterNoOnAfterValidate', '', false, false)] | ||
| local procedure OnAfterNoOnAfterValidate(var PurchaseLine: Record "Purchase Line"; xPurchaseLine: Record "Purchase Line") |
There was a problem hiding this comment.
The new EventSubscriber OnAfterNoOnAfterValidate on Page::"Purch.
Invoice Subform" declares its second parameter as xPurchaseLine: Record "Purchase Line" (no var), but the publisher (PurchInvoiceSubform.Page.al line 1593) declares it as var xPurchaseLine: Record "Purchase Line". AL requires a subscriber to reproduce the publisher's parameter list, including var/byref modifiers, verbatim. This var mismatch will fail to compile/bind. Compare with the sibling PurchCrMemoSubformNL.Codeunit.al, which correctly copies both var modifiers from its own publisher.
| local procedure OnAfterNoOnAfterValidate(var PurchaseLine: Record "Purchase Line"; xPurchaseLine: Record "Purchase Line") | |
| local procedure OnAfterNoOnAfterValidate(var PurchaseLine: Record "Purchase Line"; var xPurchaseLine: Record "Purchase Line") |
Knowledge:
👍 useful · ❤️ especially valuable · 👎 wrong - reply with why
| Access = Internal; | ||
|
|
||
| [EventSubscriber(ObjectType::Codeunit, Codeunit::"Sales-Post Prepayments", 'OnBeforePostCustomerEntry', '', false, false)] | ||
| local procedure OnBeforePostCustomerEntry(var GenJnlLine: Record "Gen. Journal Line"; SalesHeader: Record "Sales Header") |
There was a problem hiding this comment.
The new EventSubscriber OnBeforePostCustomerEntry on Codeunit::"Sales-Post Prepayments" is declared with only two parameters, `(var GenJnlLine: Record "Gen.
Journal Line"; SalesHeader: Record "Sales Header"), but the publisher (SalesPostPrepayments.Codeunit.al line 2431) declares six parameters: (var GenJnlLine: Record "Gen. Journal Line"; TotalPrepmtInvLineBuffer: Record "Prepayment Inv. Line Buffer"; TotalPrepmtInvLineBufferLCY: Record "Prepayment Inv. Line Buffer"; CommitIsSuppressed: Boolean; SalesHeader: Record "Sales Header"; DocumentType: Option Invoice,"Credit Memo")`. A subscriber cannot cherry-pick a subset of the publisher's parameters; the full parameter list, in order, must be reproduced. As written this subscriber will not bind to the publisher and the extracted NL Transaction Mode Code/Bank Account Code logic that used to run inline in the old NL override of Sales-Post Prepayments will silently stop firing.
Knowledge:
👍 useful · ❤️ especially valuable · 👎 wrong - reply with why
| @@ -7581,7 +7582,7 @@ table 36 "Sales Header" | |||
| if ReplaceVATDate then | |||
| "VAT Reporting Date" := VATDateReq; | |||
|
|
|||
| if ReplaceDocDate and ("Document Date" <> PostingDateReq) then begin | |||
| if ReplacePostingDate and ReplaceDocDate and ("Document Date" <> PostingDateReq) then begin | |||
There was a problem hiding this comment.
SalesHeader.Table.al's BatchConfirmUpdatePostingDate procedure was changed to if ReplacePostingDate and ReplaceDocDate and (...), but the procedure already exits immediately at its top with if not ReplacePostingDate then exit;.
By the time execution reaches this line, ReplacePostingDate is always true, so the added conjunct is dead/redundant code. The same change is duplicated identically across every per-country-layer copy of SalesHeader.Table.al touched by this PR (W1, NO, and others), suggesting an unrelated, mechanically-applied edit rather than an intentional fix. Recommend removing the redundant ReplacePostingDate and or clarifying the actual intent if this guard is meant to protect against a future refactor of the early exit.
| if ReplacePostingDate and ReplaceDocDate and ("Document Date" <> PostingDateReq) then begin | |
| if ReplaceDocDate and ("Document Date" <> PostingDateReq) then begin |
Agent judgement — not directly backed by a BCQuality knowledge article.
👍 useful · ❤️ especially valuable · 👎 wrong - reply with why
What & why
Linked work
Fixes AB#640601
How I validated this
What I tested and the outcome (required — be specific: scenarios, commands, screenshots for UI changes)
Risk & compatibility