The SSR transactions page listed transactions flagged
:transaction-approval-status/suppressed, which the GraphQL/CLJS page has
always excluded (auto-ap.datomic.transactions, the true branch of its
cond->>), as do the ledger queries in auto-ap.ledger. Suppressing a
transaction is the user's way of saying 'stop showing me this', so the same
transaction stayed visible on the page it was suppressed from.
The scan-transactions ion does no status filtering of its own, so nothing
downstream was dropping them: for the worst-affected client a five-year range
returned 14,736 rows against 3,641 real ones -- the other 11,095 were
suppressed. 22,813 suppressed transactions exist db-wide.
Filtered inside the query rather than after it so that the row count and the
amount total, both derived from fetch-ids, match the rows rendered. Measured
6ms -> 29ms on that worst-case client and range. The three status routes
(approved, unapproved, requires-feedback) constrain the status themselves and
there is no suppressed route, so no page loses its own rows.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A journal entry with a line posted to a bank account flagged
:bank-account/include-in-reports false shows on the SSR register but not on
the GraphQL/CLJS ledger page, which has always dropped those entries in
auto-ap.datomic.ledger/graphql-results (and the CSV export does the same in
auto-ap.routes.exports). Same entry, same filters, visible on one page and
missing from the other. The admin client form defaults the flag to false, so
any bank account saved without ticking the box is affected -- 33 of 676 bank
accounts carry an explicit false today.
Resolve the affected entries up front off VAET and drop them before sorting
rather than excluding them inside the query: the equivalent not-join measured
~36ms against ~3ms for the bare scan on a wide date range, while the two
lookups cost ~2ms and are skipped entirely for clients with nothing flagged.
Unlike the GraphQL page, which filters after pagination and so quietly serves
short pages against an unfiltered total, this runs before pagination, so the
row count matches what the register renders.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
