[Master] - Bug 645043: [Expense Agent] Expense User with missing Employee Posting Group is exposed through the Expense Users API and gets stuck at submission

[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

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Accept with Suggestions

What this PR does

This change stops Expense Users whose linked employee has no Employee Posting Group from being visible through the expenseUsers API, and it prevents creating a new invalid link through Expense User.Employee No. validation. It adds an Employee Posting Group FlowField on Expense User, filters it in Expense Users API OnOpenPage, and keeps the existing submit/posting checks intact. The root cause is addressed for both newly linked users and older records where the employee setup is later cleared.

Problem-solution fit

Fit: Strong

The reported scenario is an expense user who can sign in but cannot submit because the linked employee is missing required posting setup. The API filter handles existing bad data, and the table validation prevents the same bad link from being created again.

Suggestions

S1 (🟠 Moderate): API filter lacks end-to-end coverage
The changed API filter should be covered through the published expenseUsers endpoint. Add a test like the existing unlinked-user API test, but clear the linked employee's Employee Posting Group and assert that direct GET and collection GET hide that user. This proves the FlowField filter works in OData, not only in table validation.

Risk assessment and necessity

Risk: This touches sign-in eligibility for Expense Agent users and an Expense User validation path. The behavior is narrow, but an incorrect API filter would either still admit users who cannot submit expenses or hide valid users from the agent. The new table validation can affect setup/import flows that link users before employee posting setup is complete; that matches the posting requirement.

Necessity: The change is needed because expense submission already rejects a missing Employee Posting Group later. Blocking or hiding the user before sign-in is a clearer failure mode than allowing login and failing at submit/posting.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=10804 round=1 by=alexei-dobriansky at=2026-08-31T13:22:22Z lastSha=686bbe8c7bb6eea04a0795d2864a87f187ecb6ba reviewKey=4e4dd0e35ba8f03ab6fa65f3a15c567cb39573008cb49825116c0bbde3c4e7a1 suggestions=S1@d43527cd

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Web\ Services}$

This API page now decides sign-in eligibility in OnOpenPage, so callers depend on it exposing only committed rows. Without Rec.ReadIsolation := IsolationLevel::ReadCommitted;, a concurrent uncommitted change to Employee No. or Employee Posting Group can transiently hide or surface a user that is later rolled back. Set read isolation before applying the filters.

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);

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}

[alexei-dobriansky]

Good Sense Reviewer - Round 2

Recommendation: Accept with Suggestions

What this PR does

This PR blocks Expense Users whose linked employee has no Employee Posting Group from reaching the agent-facing API, and it prevents new invalid links through Expense User.Employee No. validation. Since round 1, the change moves the ES employee posting-group update before demo Expense Users are created, then still runs the ES country master-data creation through the common case branch. That is the right order for the new validation because the demo users now need employees to have posting groups before they are linked.

Status of previous suggestions

ID	Title	Status	Author response
S1	API filter lacks end-to-end coverage	Not addressed	No reply.

New observations (commits since round 1)

None - the new commit only adjusts ES demo-data setup order and does not add a new review finding.

Risk assessment and necessity

Risk: This still touches sign-in eligibility for Expense Agent users, setup validation for Expense Users, and demo-data creation order. The ES reorder is narrow: it sets employee posting groups before creating Expense Users and still includes ES when country-specific expense data is created. The remaining risk is that the API FlowField filter is not proven through the published endpoint.

Necessity: The change is needed because expense submission already requires an Employee Posting Group. The new ES ordering is also needed because the table validation would otherwise reject demo Expense Users before the country employee setup runs.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=10804 round=2 by=alexei-dobriansky at=2026-09-01T13:17:26Z lastSha=0ddb2afcb82b68d1c6c8968488862b2e8c887059 reviewKey=130ee25554c393add4c285255511b4640e5f0cd32776b70c6a2c7ac9d965dd72 suggestions=S1@d43527cd:notaddressed parentRound=1

[Prangshuman Das (t-prda)]

I wonder if we should completely block expense report line creation or let the admin fix the posting group during posting. That way we only block the posting scenarios.

However, the pro of this check is that the expense user config will be complete.

[Prangshuman Das (t-prda)]

Please seek Toto's opinion.

[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.