shad0w commented

Owner

Raised by

Kaushal Pal Singh (kps@pelagiamarine.com, MANAGER) — via portal Report Issue button

Description

In PO History, there is no search option with Accounting Code Search

Priority

P2 — Medium

Context

Page: /history
Reported at: 2026-06-24T07:39:56.323Z

### Raised by Kaushal Pal Singh (kps@pelagiamarine.com, MANAGER) — via portal Report Issue button ### Description In PO History, there is no search option with Accounting Code Search ### Priority P2 — Medium ### Context - Page: `/history` - Reported at: 2026-06-24T07:39:56.323Z

shad0w added the

portal

label 2026-06-24 07:39:56 +00:00

shad0w added the

feature

claude-queue

triaged

labels 2026-06-24 07:41:16 +00:00

shad0w commented

2026-06-24 07:41:17 +00:00

Author

Owner

Claude triage

Triage — Issue #121: PO History Search Options (Accounting Code Search)

Type: feature · Priority: P2 · Page: /history · Reporter: Kaushal Pal Singh (MANAGER)

Interpretation

The PO History page (/history) currently offers filters for From/To (created date),
Approved From/To, Cost Centre (vessel) and Status. The manager wants an additional
filter to narrow PO History by Accounting Code — the same "Accounting Code" construct already
modelled by the Account tree (6-digit codes, leaf items selectable on a PO). This is an
additive new filter, not a broken behaviour, so it is a feature/enhancement.

Each PurchaseOrder already carries a PO-level accountId (account relation), which is already
included in the History query — so the data is present; only a filter control + a where clause
are missing.

Action items

app/(portal)/history/page.tsx (Server Component)
- Add accountId?: string to the searchParams type.
- Fetch selectable accounting codes (leaf Accounts — those with no children, matching what a PO
  can reference; isActive and ordered by code) and pass them to HistoryFilters.
- Add if (accountId) where.accountId = accountId; to the Prisma where.
- Thread accountId into both pageParams (pagination links) and exportParams (CSV/PDF export).
app/(portal)/history/history-filters.tsx (Client Component)
- Add an Accounting Code control to the filter grid. Reuse the existing
  components/ui/searchable-select.tsx combobox (already used for accounting-code selection in the
  PO line-items editor) so a manager can type-to-search the 6-digit code/name; include an
  "All accounting codes" empty option.
- Wire it into buildParams / apply / clear / hasFilters exactly like the existing
  vesselId select.
app/api/reports/export/route.ts (CSV + PDF export)
- Read accountId from the query string and apply the same where.accountId filter so the
  Export CSV/PDF respect the on-screen filter (it already mirrors the other history filters).
Tests — extend/author a unit or staging test verifying that supplying ?accountId= narrows
the result set (mirror the existing tests/staging/issue-31-history-multi-status.spec.ts /
issue-104-history-pagination.spec.ts pattern). Optionally surface the Account column in the
table for context (the CSV already has an "Account" column).

Files / areas involved

App/app/(portal)/history/page.tsx — query where, params threading, fetch codes.
App/app/(portal)/history/history-filters.tsx — new filter control.
App/app/api/reports/export/route.ts — keep export in sync.
App/components/ui/searchable-select.tsx — reused (no change expected).
App/prisma/schema.prisma — Account model (reference only; no migration).

Open questions

Match scope: filter on the PO-level accountId only (simplest, matches displayed account)
vs. also matching POs whose line items carry the code (lineItems: { some: { accountId } }).
Recommended default: PO-level account for v1 (consistent, cheap), note line-item match as a
possible follow-up.
Leaf vs roll-up: only leaf codes are selectable on a PO, so a leaf-level single-select matches
exactly. If selecting a parent (heading/sub-heading) should include all descendant leaves, that
needs a roll-up (accountId: { in: leavesUnder(parent) }). Default: leaf-only select (exact
match) to keep it localized; roll-up is a nice-to-have.
Single-select vs multi-select (status is multi-select). Default: single-select to match the
Cost Centre control and keep acceptance crisp.

Routing rationale

Routing rationale: Localized, additive filter following an existing in-file pattern with reusable components, no DB migration / auth / payments / external systems, and verifiable by type-check + lint + a history filter test — safe for an unattended claude-queue run with a sensible PO-level leaf-match default.

Routing: claude-queue | Type: feature

## Claude triage # Triage — Issue #121: PO History Search Options (Accounting Code Search) **Type:** feature · **Priority:** P2 · **Page:** `/history` · **Reporter:** Kaushal Pal Singh (MANAGER) ## Interpretation The PO History page (`/history`) currently offers filters for **From/To** (created date), **Approved From/To**, **Cost Centre** (vessel) and **Status**. The manager wants an additional filter to narrow PO History by **Accounting Code** — the same "Accounting Code" construct already modelled by the `Account` tree (6-digit codes, leaf items selectable on a PO). This is an **additive new filter**, not a broken behaviour, so it is a *feature/enhancement*. Each `PurchaseOrder` already carries a PO-level `accountId` (`account` relation), which is already `include`d in the History query — so the data is present; only a filter control + a `where` clause are missing. ## Action items 1. **`app/(portal)/history/page.tsx`** (Server Component) - Add `accountId?: string` to the `searchParams` type. - Fetch selectable accounting codes (leaf `Account`s — those with no children, matching what a PO can reference; `isActive` and ordered by `code`) and pass them to `HistoryFilters`. - Add `if (accountId) where.accountId = accountId;` to the Prisma `where`. - Thread `accountId` into both `pageParams` (pagination links) and `exportParams` (CSV/PDF export). 2. **`app/(portal)/history/history-filters.tsx`** (Client Component) - Add an **Accounting Code** control to the filter grid. Reuse the existing `components/ui/searchable-select.tsx` combobox (already used for accounting-code selection in the PO line-items editor) so a manager can type-to-search the 6-digit code/name; include an "All accounting codes" empty option. - Wire it into `buildParams` / `apply` / `clear` / `hasFilters` exactly like the existing `vesselId` select. 3. **`app/api/reports/export/route.ts`** (CSV + PDF export) - Read `accountId` from the query string and apply the same `where.accountId` filter so the Export CSV/PDF respect the on-screen filter (it already mirrors the other history filters). 4. **Tests** — extend/author a unit or staging test verifying that supplying `?accountId=` narrows the result set (mirror the existing `tests/staging/issue-31-history-multi-status.spec.ts` / `issue-104-history-pagination.spec.ts` pattern). Optionally surface the Account column in the table for context (the CSV already has an "Account" column). ## Files / areas involved - `App/app/(portal)/history/page.tsx` — query `where`, params threading, fetch codes. - `App/app/(portal)/history/history-filters.tsx` — new filter control. - `App/app/api/reports/export/route.ts` — keep export in sync. - `App/components/ui/searchable-select.tsx` — reused (no change expected). - `App/prisma/schema.prisma` — `Account` model (reference only; **no migration**). ## Open questions - **Match scope:** filter on the **PO-level `accountId`** only (simplest, matches displayed account) vs. also matching POs whose **line items** carry the code (`lineItems: { some: { accountId } }`). Recommended default: **PO-level account** for v1 (consistent, cheap), note line-item match as a possible follow-up. - **Leaf vs roll-up:** only leaf codes are selectable on a PO, so a leaf-level single-select matches exactly. If selecting a parent (heading/sub-heading) should include all descendant leaves, that needs a roll-up (`accountId: { in: leavesUnder(parent) }`). Default: **leaf-only select** (exact match) to keep it localized; roll-up is a nice-to-have. - Single-select vs multi-select (status is multi-select). Default: **single-select** to match the Cost Centre control and keep acceptance crisp. ## Routing rationale Routing rationale: Localized, additive filter following an existing in-file pattern with reusable components, no DB migration / auth / payments / external systems, and verifiable by type-check + lint + a history filter test — safe for an unattended claude-queue run with a sensible PO-level leaf-match default. **Routing:** `claude-queue` | **Type:** `feature`

shad0w added

claude-working

and removed

claude-queue

labels 2026-06-24 07:41:17 +00:00

shad0w commented

2026-06-24 07:41:17 +00:00

Author

Owner

[Claude] Started working on this issue on branch claude/issue-121.

[Claude] Started working on this issue on branch `claude/issue-121`.

shad0w referenced this issue from a pull request that will close it,

2026-06-24 07:48:13 +00:00

fix: PO History Search Options #123

shad0w added

claude-pr

and removed

claude-working

labels 2026-06-24 07:48:14 +00:00

shad0w commented

2026-06-24 07:48:14 +00:00

Author

Owner

[Claude] Opened PR #123 with a proposed fix. Review and merge it, then create a release tag to deploy.

[Claude] Opened PR [#123](https://git.pelagiamarine.com/shad0w/pelagia-portal/pulls/123) with a proposed fix. Review and merge it, then create a release tag to deploy.

shad0w referenced this issue from a commit

2026-06-24 07:48:14 +00:00

feat(history): add Accounting Code search filter to PO History

shad0w closed this issue

2026-06-25 20:59:34 +00:00

Rows
Columns

[Issue]: PO History Search Options #121

Raised by

Description

Priority

Context

Claude triage

Triage — Issue #121: PO History Search Options (Accounting Code Search)

Interpretation

Action items

Files / areas involved

Open questions

Routing rationale