Repository navigation
[$175] [CFI][FE 5/7] Payment history: Activity list with the active user count #101832
Description
Sub-task of [CFI] Add a "View payment history" page with historical billing receipts and monthly user activity.
Goal
The details page has an Activity section listing the members who were billed that month, with the total count shown under the Activity header.
Scope
- Available for every row, including
Failedmonths. This is a deliberate improvement over Classic, whereFailedrows show only "View activity" andClearedrows show only "View receipt". - The total count goes under the
Activityheader — never next to the billed amount. See the note in FE 2/7 for why. - The billed members come from the per-policy actor list on the purchase message (
message.billablePolicies[*].actorList, already declared as a comma-separated email string insrc/types/onyx/PurchaseList.ts). Dedupe across policies — the same person can be billed under more than one workspace. - Make the list searchable. These lists run to hundreds of emails on large accounts, and the mock included a search field.
- Copy in every
src/languages/*.tslocale. Use the "active users" wording here; the Collect-plan "members" variant is FE 7/7.
Acceptance criteria
- Activity is reachable from every row,
FailedandClearedincluded. - The total count matches the number of deduped, billed members for that month.
- Searching filters the list.
- A month with no billed members renders an empty state rather than a blank section.
- Renders correctly wide and narrow.
Depends on
FE 4/7, and a backend decision that needs confirming before this is built: whether the actor list ships with the table payload or is fetched when the details page opens. The actor list is the bulk of the payload and it is large for long-lived, high-headcount accounts, so the split is being decided in the backend issue. Check the agreed contract first.
Easy to get wrong
- Counting the raw comma-separated string length per policy and summing it, which double-counts anyone billed under multiple workspaces.
- Rendering hundreds of rows without a virtualised list.
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~022112911890208645145
- Upwork Job ID: 2112911890208645145
- Last Price Increase: 2026-10-21
Metadata
Metadata
Labels
Type
Projects
- Status
Activity
dukenv0307 commentedon Oct 1, 2026
Not overdue
2 remaining items
dukenv0307 commentedon Oct 8, 2026
Not overdue
dukenv0307 commentedon Oct 12, 2026
Not overdue
dukenv0307 commentedon Oct 19, 2026
@MelvinBot Implement. Here's the parent issue: #101649 and make sure the activity list components are similar to
MelvinBot commentedon Oct 19, 2026
🤖 Draft PR created: [CFI] Payment history: Activity list with the active user count
Please mark it as "Ready for review" or ask me to do that for you when it is ready for review.
The Payment details page now has an Activity section that matches your mock: an
Activitylabel, a "Find an active user" search field, and a rounded card. The card header shows the count (for example, "2 active users"), and each row shows the user's avatar, name, and email.FailedandCleared. A month with no billed members shows "No active users this month." instead of a blank section.SelectionList, so long lists only render visible rows. Search filters by name or email.Things to check
purchase.activeUsers, the account IDs thatOpenPaymentDetailsPagereturns, as declared inPurchaseList.tsby FE 4/7. If the backend sends rawactorListemails instead, only the helper and the item mapping need to change.view run · no recording available
[-][CFI][FE 5/7] Payment history: Activity list with the active user count[/-][+][$175] [CFI][FE 5/7] Payment history: Activity list with the active user count[/+]melvin-bot commentedon Oct 21, 2026
Job added to Upwork: https://www.upwork.com/jobs/~022112911890208645145