[Bug Fix] #638531: Disable Open TO from PO actions on non-subcontracting lines

[ventselartur]

Summary

The "Open TO from PO" actions on the subcontracting Purchase Order lines (Transfer Order / Return Transfer Order) are now disabled when the current line is not a subcontracting line, instead of appearing enabled but silently doing nothing.

Root Cause

The Transfer Order and Return Transfer Order actions in pageextension 99001524 "Subc. PO Subform" call SubcPurchFactboxMgmt.ShowTransferOrdersAndReturnOrder(Rec, ...), which requires the current purchase line's Prod. Order No. and exit(0)s when it is empty. The enclosing group(Production) was gated only at the document level (Visible = HasSubcontractingContext), never per line. So on a component/non-subcontracting line the actions stayed enabled but did nothing - a usability/discoverability defect.

Changes Made

• src/Apps/W1/Subcontracting/App/src/Purchase/SubcPOSubform.PageExt.al: Added an OnAfterGetCurrRecord trigger that computes CurrentLineIsSubcontractingLine from Subcontracting Management.IsSubcontractingPurchaseLine(Rec), and set Enabled = CurrentLineIsSubcontractingLine on action("Transfer Order") and action("Return Transfer Order").
• src/Apps/W1/Subcontracting/Test/Tests/SubcSubcontractingTest.Codeunit.al: Added regression test TransferOrderActionDisabledOnNonSubcontractingPurchaseLine.

Implementation Process

• Fix iterations: 1
• Compilation: All projects compile successfully (full al_build, scope=all)
• Tests: All tests passing

Test Evidence

Pre-Fix Test Results (Baseline)

Run without the fix (deterministic across 3 runs):

FAIL TransferOrderActionDisabledOnNonSubcontractingPurchaseLine
     Assert.IsFalse failed. Transfer Order action must be disabled for a
     non-subcontracting purchase line (no Prod. Order No.).

Post-Fix Test Results (Final)

PASS TransferOrderActionDisabledOnNonSubcontractingPurchaseLine
Test run completed: 3 passed, 0 failed, 0 skipped.

Test Coverage

• New regression test for work item #638531
• Action enabled on a subcontracting line (Prod. Order No. set)
• Action disabled on a non-subcontracting line (no Prod. Order No.) on the same order

Review Notes

The fix relies on the existing internal Subcontracting Management.IsSubcontractingPurchaseLine, which returns true only when Prod. Order No. and Prod. Order Line No. are set.

Fixes: AB#638531

[alexei-dobriansky]

Agentic PR Review - Round 1

Recommendation: Accept with Suggestions

What this PR does

The fix disables the "Transfer Order" and "Return Transfer Order" actions on the subcontracting Purchase Order subform when the current line is not a subcontracting line. Before the fix these actions stayed enabled on component or other non-subcontracting lines but did nothing, because SubcPurchFactboxMgmt.ShowTransferOrdersAndReturnOrder exits early when the line has no Prod. Order No..

The change is correct and targets the root cause. A new global CurrentLineIsSubcontractingLine is set in OnAfterGetCurrRecord from Subcontracting Management.IsSubcontractingPurchaseLine(Rec), and both actions bind Enabled to it. IsSubcontractingPurchaseLine returns true only when Prod. Order No. <> '' and Prod. Order Line No. <> 0, which is exactly the condition under which the action would otherwise do nothing. OnAfterGetCurrRecord fires when the focused line changes, so the enabled state is re-evaluated per line. This matches the expected behavior in the work item ("make the action disabled if it is not a subcontracting line").

Suggestions

S1 - Same silent no-op on the Production Order actions
The sibling actions "Production Order", "Production Order Routing", and "Production Order Components" in the same group also call code that exits early when the line has no Prod. Order No. (see SubcProdOFactboxMgmt.ShowProductionOrder). On a non-subcontracting line they stay enabled but do nothing, which is the same usability defect this PR fixes. Consider giving them the same Enabled = CurrentLineIsSubcontractingLine gate for consistency.

S2 - Test does not cover the Return Transfer Order action
The new test asserts Enabled only on the "Transfer Order" action. The "Return Transfer Order" action received the identical change but is not checked. Add an assertion on PurchaseOrderPage.PurchLines."Return Transfer Order".Enabled() for both the subcontracting and the non-subcontracting line so both changed actions are covered.

Risk assessment and necessity

Risk: Low. The change is limited to the enabled state of two actions on one page extension (SubcPOSubform.PageExt.al) and does not change any posting, amount, or data logic. It only reads the current line and toggles Enabled; no public API or event signature changes. The main regression surface is the action being wrongly disabled on a valid subcontracting line, but the enable condition reuses the same IsSubcontractingPurchaseLine helper the underlying action already depends on, so the states stay aligned.

Necessity: Justified. The linked Bug 638531 (Severity 3, Priority 2) describes a real usability and discoverability defect: users on component lines see an enabled action that does nothing. The scope is right for a bug fix - two small property additions plus one trigger line, with a regression test that verifies both the enabled and disabled states. Without the change users stay confused by an action that appears usable but is not.

---

[AI-PR-REVIEW] version=1 system=github pr=8752 round=1 by=alexei-dobriansky at=2026-08-03T17:19:54Z lastSha=15e81b161bbeaf84025eaa44c3a7b1dd1b7cbae6 suggestions=S1,S2

[github-actions]

⚠️ Stale Status Check Deleted

The Pull Request Build workflow run for this PR was older than 72 hours and has been deleted.

📋 Why was it deleted?

Status checks that are too old may no longer reflect the current state of the target branch. To ensure this PR is validated against the latest code and passes up-to-date checks, a fresh build is required.

---

🔄 How to trigger a new status check:

1. 📤 Push a new commit to the PR branch, or
2. 🔁 Close and reopen the PR

This will automatically trigger a new Pull Request Build workflow run.