Expense Agent: require Employee Posting Group when linking an expense user

[v-rohangarg20]

Fixes AB#645043

Problem

An expense user linked to an employee without an Employee Posting Group was returned by the Expense Users API. The agent could sign that user in, but submission/posting later failed because the posting group is required.

Changes

• Expense User.Employee No. validation now errors when the employee has no employee posting group, so such a link cannot be created.
• Added the Employee Posting Group lookup FlowField (field 25) on Expense User and filtered on it in Expense Users API OnOpenPage (FilterGroup 2, next to the existing Employee No. filter). This also covers employees whose posting group is removed after the link was made.

Tests

• ExpenseUserCannotBeLinkedToEmployeeWithoutPostingGroup
• ExpenseUserCanBeLinkedToEmployeeWithPostingGroup

[v-rohangarg20]

Superseded by #10804 (branch renamed to bugs/645043-expense-user-employee-posting-group).

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Breaking\ Changes}$

The new FilterGroup 2 filter on "Employee Posting Group" changes the externally observable contract of API page 6918 "Expense Users API": expense users that were previously returned now disappear whenever the linked employee has a blank posting group. This is an advisory agent finding, but for API consumers it behaves like a breaking change because existing records become indistinguishable from "not found". Keep the existing collection shape stable and expose posting-group readiness separately, or version the API behavior explicitly.

Line mapping was unavailable, so this was posted as an issue comment.

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

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Breaking\ Changes}$

Adding a new error to the existing "Employee No." validation path changes the shipped behavior of table 6923 "Expense User": code and UI flows that previously linked an employee now fail when that employee has no posting group. This is an advisory agent finding, but in practice it can break existing integrations and customer data-maintenance flows. Preserve the old linking contract and enforce the posting-group requirement in a compatible way, such as at posting/submission time or behind a migration/grandfathering path.

Line mapping was unavailable, so this was posted as an issue comment.

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

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Error\ Handling}$

This validation already knows the exact Employee record that must be corrected, but it raises a plain Error with no recommended action. Use ErrorInfo with a Show-it navigation action (RecordId/PageNo plus AddNavigationAction) so the user can open the Employee and set Employee Posting Group instead of being left at a dead-end dialog.

Knowledge:

• microsoft/knowledge/error-handling/prefer-errorinfo-for-actionable-errors.md

Line mapping was unavailable, so this was posted as an issue comment.

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

[github-actions]

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

The new negative test pins asserterror to a test-local copy of the full production error sentence (EmployeePostingGroupMissingErr). That still leaves the assertion coupled to duplicated message text instead of a shared assert helper or a stable invariant fragment, so wording drift between app and test can break or misdirect the check even when the validation behavior is still correct.

Knowledge:

• microsoft/knowledge/testing/asserterror-needs-expectederror-and-code.md

Line mapping was unavailable, so this was posted as an issue comment.

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

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Web\ Services}$

This API now decides gateway sign-in eligibility in OnOpenPage() by filtering out users with no linked employee or no employee posting group, but it still leaves reads at the default isolation. A concurrent uncommitted change to either value can therefore make the gateway temporarily admit or reject a user based on data that later rolls back. Set Rec.ReadIsolation := IsolationLevel::ReadCommitted; before applying the filters so the endpoint exposes only committed eligibility data.

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

    begin
        Rec.ReadIsolation := IsolationLevel::ReadCommitted;

        // Expense Users without a linked Employee No. cannot post expenses
        // (validation fails at submission), so don't surface them to the agent
        // gateway. The gateway treats an absent user as "not in this environment"
        // and blocks sign-in there. Apply the constraint in FilterGroup 2 so it
        // AND-combines with any caller-supplied $filter on Employee No., rather
        // than replacing it in the default FilterGroup 0.
        // The same applies when the employee posting group was removed from the
        // employee after the expense user was linked.
        OriginalFilterGroup := Rec.FilterGroup();
        Rec.FilterGroup(2);
        Rec.SetFilter("Employee No.", '<>%1', '');
        Rec.SetFilter("Employee Posting Group", '<>%1', '');
        Rec.FilterGroup(OriginalFilterGroup);
    end;

Knowledge:

• microsoft/knowledge/web-services/expose-only-committed-data-from-api-reads.md

Line mapping was unavailable, so this was posted as an issue comment.

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