[BTAPI-65] Add GET /one-time/transactions #82

Merged

chris merged 4 commits from feature/BTAPI-65 into main

2026-08-30 11:39:28 -06:00

chris commented

2026-08-30 11:30:23 -06:00

Owner

Ticket

BTAPI-65 Add GET /one-time/transactions — one-time transactions for a calendar year

Summary

Adds GET /one-time/transactions?year=YYYY, returning every one-time-tagged transaction for a calendar year (defaulting to the current year in America/Edmonton), newest first. Backs the upcoming One-Time screen (BTAPP-50), which is blocked on this ticket.
Validated via a new oneTimeTransactionsQuerySchema (four-digit integer, optional); malformed years return 400, an empty year returns 200 [].
Extracted a shared currentYear()/yearWindow(year) pair into @lib/budget (alongside the existing startOfBudgetWeek/countsTowardBudget) so the calendar-year-window computation isn't duplicated across the new route, the one-time data layer, and the pre-existing tag-summary window — getSummaries in @lib/tags now uses the same helper.
Full test coverage at all three layers (schema, data layer, route), including the Edmonton-timezone year boundary (both ends), refunds/credits, and transactions carrying an ignoring tag rather than the ignored flag.

Deferred

A performance review found getTransactionsForYear/spentFromPool walk every one-time-tagged transaction ever recorded rather than just the requested year, since no index currently covers tags.name + date together. Measured impact is ~1ms at household data volumes — confirmed low severity and deliberately not addressed here. A compound index { 'tags.name': 1, date: -1 } in ensureIndexes() (server/lib/data/transaction/index.ts) would close this if it's ever worth doing.

## Ticket [BTAPI-65](http://192.168.2.100:7123/home/browse/BTAPI-65/) Add GET /one-time/transactions — one-time transactions for a calendar year ## Summary - Adds `GET /one-time/transactions?year=YYYY`, returning every one-time-tagged transaction for a calendar year (defaulting to the current year in `America/Edmonton`), newest first. Backs the upcoming One-Time screen (BTAPP-50), which is blocked on this ticket. - Validated via a new `oneTimeTransactionsQuerySchema` (four-digit integer, optional); malformed years return 400, an empty year returns `200 []`. - Extracted a shared `currentYear()`/`yearWindow(year)` pair into `@lib/budget` (alongside the existing `startOfBudgetWeek`/`countsTowardBudget`) so the calendar-year-window computation isn't duplicated across the new route, the one-time data layer, and the pre-existing tag-summary window — `getSummaries` in `@lib/tags` now uses the same helper. - Full test coverage at all three layers (schema, data layer, route), including the Edmonton-timezone year boundary (both ends), refunds/credits, and transactions carrying an ignoring tag rather than the `ignored` flag. ## Deferred A performance review found `getTransactionsForYear`/`spentFromPool` walk every one-time-tagged transaction ever recorded rather than just the requested year, since no index currently covers `tags.name` + `date` together. Measured impact is ~1ms at household data volumes — confirmed low severity and deliberately not addressed here. A compound index `{ 'tags.name': 1, date: -1 }` in `ensureIndexes()` (`server/lib/data/transaction/index.ts`) would close this if it's ever worth doing.

chris added 4 commits

2026-08-30 11:30:23 -06:00

[BTAPI-65] Add oneTimeTransactionsQuerySchema for the year query param. 7dff36f4a1

[BTAPI-65] Add OneTimeService.getTransactionsForYear data-layer query. 4b550903a6

[BTAPI-65] Add GET /one-time/transactions route for a calendar year. e8ff72632c

[BTAPI-65] Address pre-PR review.

server / check (pull_request) Successful in 32s

Details

plane-sync / sync (pull_request) Successful in 1s

Details

39faeb337f

chris merged commit 6836f79772 into main