Transaction rebrand page — test report

D1Download Statement is unusable on a direct load or refresh of the Transactions page

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.

D2Export CSV ignores the row selection

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.

D3Transaction Type = Incoming returns nothing

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.

AC2Defaults

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.

AC3Filters apply immediately and live in the URL

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.

AC4Summary line and Clear filters

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.

AC5Row details and credit wording

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.

AC6Receipts download as PDF — loading confirmed, error path not exercisable

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.

AC7 (part)Rows selectable; CSV columns intact

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

AC8Statement download from a saved / shared link — Fail

Land on /transactions directly (bookmark, shared link, or reload) and the statement flow cannot be started at all: the currency dropdown is empty and the button is disabled. The five sub-behaviours pass once you reach the page by in-app navigation, so the feature is not broken — this one entry path is. Full detail in D1.

AC8a100-day cap

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.

AC8b / AC8cBackground, minimise, Maximize

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

AC8dNo-data range

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.

AC8eClose mid-download confirms

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.

AC1Page hidden without view-transaction permission

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.

The guard is real and route-level, not just the nav. In the served Transactions route chunk (page-84adc…) the component reads VIEW_TRANSACTION and returns early: You do not have permission to view transactions. So AC1 should pass the moment an account without the permission exists — but that is source-level evidence, not a live pass.