[Issue]: Dashboard PO count shows wrong number #41

New issue

Closed

opened 2026-06-19 08:41:12 +00:00 by shad0w · 1 comment

shad0w commented

2026-06-19 08:41:12 +00:00

Owner

Description

The 'Total Purchase Orders' card on the dashboard shows a number that does not match the actual count of POs. It looks like a counting bug.

### Description The 'Total Purchase Orders' card on the dashboard shows a number that does not match the actual count of POs. It looks like a counting bug.

shad0w added the

portal

label 2026-06-19 08:41:12 +00:00

shad0w added the

bug

interactive

triaged

labels 2026-06-19 08:43:29 +00:00

shad0w commented

2026-06-19 08:43:29 +00:00

Author

Owner

Claude triage

Triage — Issue #41: Dashboard PO count shows wrong number

Summary

The "Total Purchase Orders" card on the dashboard reportedly shows a number that
doesn't match the actual count of POs ("a counting bug"). Investigation shows the
underlying count query is already correct, so the report is either a perception
mismatch or an unstated expectation. There is no reproduction, no role, and no
expected-vs-actual numbers — the defect cannot be pinned down or verified without
clarification from the reporter.

Where the card lives

The label "Total Purchase Orders" appears in exactly one place:
app/(portal)/dashboard/page.tsx:263, inside GenericDashboard.
GenericDashboard renders for roles other than TECHNICAL / MANNING /
SUPERUSER / MANAGER / ACCOUNTS — i.e. AUDITOR and ADMIN (page.tsx:13-29).
The card value is const total = await db.purchaseOrder.count(); (page.tsx:258)
— an unfiltered count of every PurchaseOrder row, which is the correct figure
for something labelled "Total".
The card links to /history (href="/history").

What I checked

Schema (prisma/schema.prisma, model PurchaseOrder): no deletedAt /
soft-delete / archived flag, so count() has no rows it ought to be excluding —
the unfiltered count is genuinely "all POs".
/history (app/(portal)/history/page.tsx): the listing query is capped at
take: 200 (line 64) and is gated behind the export_reports permission. With
prod-like data (staging mirrors production), there may be more than 200 POs, so
a user who clicks the card and counts the visible rows will see 200 while the card
shows the true total — a likely source of the perceived mismatch, but not a bug in
the card itself.
Other count cards in the dashboard (Open Orders, Pending Approval,
Completed Orders, etc.) use deliberate status filters; none is labelled "Total
Purchase Orders".

Action items (pending clarification)

Reproduce: confirm which role/dashboard the reporter saw (the card only renders for
AUDITOR/ADMIN) and capture the displayed number vs the "actual count" they compared
against.
Determine the intended definition of "Total Purchase Orders":
- all rows (current behaviour — correct), or
- excluding DRAFT / never-submitted POs, or
- matching the /history list the card links to.
If the mismatch is the /history take: 200 cap, decide on the desired remedy
(show a total-results count on history, paginate, or relink the card) — a larger
product/UX decision, not a one-line count fix.

Files / areas involved

app/(portal)/dashboard/page.tsx (GenericDashboard, line 258/263) — primary.
app/(portal)/history/page.tsx (200-row cap, line 64) — likely related to the
perceived discrepancy.
components/dashboard/stat-card.tsx — presentation only; no defect.

Open questions

Which role saw the card, and what were the exact "shown" vs "expected" numbers?
Should "Total" exclude DRAFTs / cancelled POs, or remain a true count of all rows?
Is the comparison being made against the (200-capped) /history list?

Routing rationale: The literal code (db.purchaseOrder.count()) is already correct and the report lacks any reproduction, role, or numbers, so there is no clear, test-verifiable defect to fix — it needs human clarification of the expected count, making this interactive rather than claude-queue.

Routing: interactive | Type: bug

## Claude triage # Triage — Issue #41: Dashboard PO count shows wrong number ## Summary The "Total Purchase Orders" card on the dashboard reportedly shows a number that doesn't match the actual count of POs ("a counting bug"). Investigation shows the underlying count query is already correct, so the report is either a perception mismatch or an unstated expectation. There is no reproduction, no role, and no expected-vs-actual numbers — the defect cannot be pinned down or verified without clarification from the reporter. ## Where the card lives - The label **"Total Purchase Orders"** appears in exactly one place: `app/(portal)/dashboard/page.tsx:263`, inside `GenericDashboard`. - `GenericDashboard` renders for roles **other than** TECHNICAL / MANNING / SUPERUSER / MANAGER / ACCOUNTS — i.e. **AUDITOR and ADMIN** (`page.tsx:13-29`). - The card value is `const total = await db.purchaseOrder.count();` (`page.tsx:258`) — an **unfiltered count of every PurchaseOrder row**, which is the correct figure for something labelled "Total". - The card links to `/history` (`href="/history"`). ## What I checked - **Schema** (`prisma/schema.prisma`, `model PurchaseOrder`): no `deletedAt` / soft-delete / archived flag, so `count()` has no rows it ought to be excluding — the unfiltered count is genuinely "all POs". - **`/history`** (`app/(portal)/history/page.tsx`): the listing query is capped at `take: 200` (line 64) and is gated behind the `export_reports` permission. With prod-like data (staging mirrors production), there may be **more than 200 POs**, so a user who clicks the card and counts the visible rows will see 200 while the card shows the true total — a likely source of the perceived mismatch, but not a bug in the card itself. - **Other count cards** in the dashboard (`Open Orders`, `Pending Approval`, `Completed Orders`, etc.) use deliberate status filters; none is labelled "Total Purchase Orders". ## Action items (pending clarification) 1. Reproduce: confirm which role/dashboard the reporter saw (the card only renders for AUDITOR/ADMIN) and capture the displayed number vs the "actual count" they compared against. 2. Determine the intended definition of "Total Purchase Orders": - all rows (current behaviour — correct), or - excluding DRAFT / never-submitted POs, or - matching the `/history` list the card links to. 3. If the mismatch is the `/history` `take: 200` cap, decide on the desired remedy (show a total-results count on history, paginate, or relink the card) — a larger product/UX decision, not a one-line count fix. ## Files / areas involved - `app/(portal)/dashboard/page.tsx` (`GenericDashboard`, line 258/263) — primary. - `app/(portal)/history/page.tsx` (200-row cap, line 64) — likely related to the perceived discrepancy. - `components/dashboard/stat-card.tsx` — presentation only; no defect. ## Open questions - Which role saw the card, and what were the exact "shown" vs "expected" numbers? - Should "Total" exclude DRAFTs / cancelled POs, or remain a true count of all rows? - Is the comparison being made against the (200-capped) `/history` list? Routing rationale: The literal code (`db.purchaseOrder.count()`) is already correct and the report lacks any reproduction, role, or numbers, so there is no clear, test-verifiable defect to fix — it needs human clarification of the expected count, making this interactive rather than claude-queue. **Routing:** `interactive` | **Type:** `bug`

shad0w closed this issue

2026-06-19 08:43:45 +00:00