ENGW-210 (parent) · ENGW-222 (TEST subtask) · run 2026-10-15
| # | AC | Result |
|---|---|---|
| AC1 | Page hidden without view-transaction permission | ⛔ Blocked — no role lacks view_transaction |
| AC2 | Defaults: last 6 months, all currencies, all types, 10 rows/page | ✅ Pass |
| AC3 | Filters apply immediately and are kept in the URL (reload / shared link restores) | ✅ Pass |
| AC4 | Summary line describes active filters; Clear filters resets | ✅ Pass |
| AC5 | Row details open; credits use incoming wording | ✅ Pass |
| AC6 | Receipts download as PDF, with loading and error feedback | ⚠️ Partial — loading confirmed, error path unreachable |
| AC7 | Rows selectable per page and exported; CSV keeps values in their own column | ❌ Fail — export ignores the selection |
| AC8a | Statement range capped at 100 days | ✅ Pass |
| AC8b | Statement runs in the background and can be minimised | ✅ Pass |
| AC8c | Maximize reopens it on any page | ✅ Pass |
| AC8d | A range with no data says so | ✅ Pass |
| AC8e | Closing mid-download asks for confirmation | ✅ Pass |
AC8 items were verified on the path where the statement modal is reachable. On a direct load or refresh of /transactions the modal cannot be used at all — see D1. That is the defect that matters most for this page. The statement-permission clause of AC8 also holds: the OPERATIONS and MEMBER roles (no view_statement) get no Download Statement button.
Open the Transactions page directly (bookmark, shared link, or reload), click Download Statement, and the Currency dropdown is empty — No matches found. Currency is required, so the submit button stays disabled and no statement can be produced.
The dropdown is fed by currency-list?type=allex (HTTP 200; 23 rows, 21 FIAT). In the bundle the option list is built by Y4(), which marks a currency disabled when it has no entry in the shared wallet-balance context and then drops every disabled row. The dashboard page pushes balances into that context (setAllBalances, dashboard chunk page-28b…); no such call is reached from the Transactions page, which fetches the balances but never puts them where Y4 reads them — so a direct hit on /transactions opens the modal with an empty balance list and every currency is filtered out.
The same modal works when you reach Transactions by in-app navigation from the dashboard: 7 currencies appear and the statement downloads normally. So this breaks exactly the bookmarked/shared-link case that AC3 is meant to support, and it blocks AC8 for anyone landing on the page directly.
Fix direction: the Transactions page should populate the same balance context (or Y4 should not require it) so the currency list does not depend on which page the user landed on first.
Select two rows — the UI confirms 2 Transactions Selected — then click Export CSV. The file contains the header plus all five rows on the page, not the two selected. Selection does not drive the export, so "rows can be selected per page and exported" is not met.
Filtering by Transaction Type Incoming shows No Transactions Yet (0 of 0), even though the account has three incoming credits on the page (+$1,000,000.00, +₦1,000,000.00, +₦99,800.00). The request sends transType: "Incoming" and the backend answers 0 transaction(s) found. Outgoing does return rows (the two debits); Payment also returns nothing. The credits carry transactionType: INTERNAL_COLLECTION, which the backend does not classify as incoming — so this may be a backend mapping rather than FE, but the user-facing filter is wrong either way.
Fresh load: 15/04/2026 – 15/10/2026 (six months), Transaction Type All Types, Currency All Currencies, Rows per page 10. Minor: the first wallet-history call is sent with pageSize: 5 before correcting to 10 — harmless with 5 rows, worth a look.

Search by ID, date range, type and currency each fire a request on change and write to the URL: ?id=, ?type=, ?currency=, ?from=, ?to=. Reload restores them; opening the URL in a fresh page restores the selects, dates and the summary line.

The line reads Showing outgoing transaction details for … as filters change, and Clear filters resets the selects, the URL and the summary to the default six-month view.

Clicking a row opens a details drawer with a status tracker. A credit shows Amount Received, Total Credited, Sender Details and narration Direct Credit; a debit shows Amount Sent, Total Debited, Recipient Details.

The drawer's Download PDF Receipt downloads a real one-page PDF (wallet-transaction-CCPP-20260904190738-111800-receipt.pdf, opens and renders). Loading feedback is real but brief: a spinner replaces the button at ~300 ms and the button returns at ~760 ms (screenshots/T6b-loading.json). The error half of the AC has no reachable trigger — the PDF is rendered client-side from data already on the page, so there is no network failure to force. Note the file is 18.9 MB for one page.

Per-page checkboxes and select-all work (5 Transactions Selected). The CSV keeps each value in its own column — quoted values with commas stay in one cell, header Transaction ID, Date and Time, Payment Method, Status, Amount. The defect is that selection does not restrict the export (D2).

101 days: Date range cannot exceed 100 days, submit disabled, no request fired. Exactly 100 days is allowed (boundary correct). A reversed range is guarded with End date cannot be before start date.

Submitting minimises to a Statement in progress card. It persists across in-app navigation (Wallet, Dashboard, back to Transactions) and Maximize reopens the download. On a full page reload the job is lost (client-side state, no persistence) — acceptable reading is in-app "any page".

A valid range with no data returns an informational No Transactions Found dialog ("We couldn't find any transactions in your NGN wallet between 1 Jan 2026 and 31 Jan 2026. Try a different date range.") with Close / Change dates. This is the empty state ENGW-191 flagged as "Download failed"; it is now correct.

Closing while the statement is being prepared raises Cancel This Download? — "Your statement is still being prepared. If you close now, you won't receive this download when it finishes." with Keep waiting / Cancel download.

Blocked, and creating an account will not unblock it. Every available role carries view_transaction — audited live: OPERATIONS and MEMBER (the restricted members from ENGW-169) log in, keep the Transactions nav entry, and the page renders normally; only the statement button is withheld (no view_statement). The invite flow offers the same fixed roles (FINANCE / MEMBER / OPERATIONS / OWNER / SUPPORT), so a new team member would also have view_transaction. There is no role without it, so the page can never be hidden for anyone.
Bundle evidence agrees: the dashboard gates the Recent Transactions block and the /transactions link on VIEW_TRANSACTION. Changes nothing here because nothing reaches it without the permission. Unblocking needs a role (or toggle) without view_transaction.
go-dev.mypasspoint.com; network payloads and responses captured per run (screenshots/*-results.json, *.json).POST /api/bff/reports → poll /status → /data (same endpoint as ENGW-191).bundle-scan/): option list built by Y4() in chunk 2119-….screenshots/coords.json).ENGW-210 / ENGW-222 · 15 Oct 2026 · Chibuzor Obilom. Comments drafted, not posted.