shad0w/pelagia-portal

Fork 0

[Issue]: Remove the Approved From and Approved to search field #136

New issue

Closed

opened 2026-06-25 21:47:41 +00:00 by shad0w · 3 comments

shad0w commented

2026-06-25 21:47:41 +00:00

Owner

Raised by

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

Description

It's unnecessary.

Priority

P2 — Medium

Context

Page: /history
Reported at: 2026-06-25T21:47:41.870Z

### Raised by Kaushal Pal Singh (kps@pelagiamarine.com, MANAGER) — via portal Report Issue button ### Description It's unnecessary. ### Priority P2 — Medium ### Context - Page: `/history` - Reported at: 2026-06-25T21:47:41.870Z

shad0w added the

portal

label 2026-06-25 21:47:41 +00:00

shad0w added the

feature

claude-queue

triaged

labels 2026-06-25 21:51:10 +00:00

shad0w commented

2026-06-25 21:51:10 +00:00

Author

Owner

Claude triage

Triage — Issue #136: Remove the "Approved From" and "Approved To" search fields

Page: /history (PO History) · Priority: P2 · Raised by: Kaushal Pal Singh (MANAGER)

Interpretation

The PO History filter bar currently exposes two date inputs — "Approved From" and
"Approved To" — that filter POs by their approval date (approvedAt), in addition to the
existing From/To (created-date) range. The manager considers these two fields unnecessary
and wants them removed from the filter UI.

This is a UI simplification: drop the two date pickers from the History filter form. The
intent is the visible search fields, not necessarily the underlying URL-param machinery,
which is also used by deep-links from elsewhere (see open questions).

Action items

app/(portal)/history/history-filters.tsx (primary, client component) — remove:
- The two <div> blocks rendering the "Approved From" and "Approved To" <input type="date"> fields (lines ~115–124).
- Their approvedFrom / approvedTo useState hooks (lines 39–40) and setter usages.
- Their entries in buildParams() (lines 68–69), clear() (line 86), and the hasFilters
  check (line 93).
Verify the grid still lays out cleanly — the filter grid is sm:grid-cols-4; removing
two cells leaves From, To, Cost Centre, Accounting Code, Status (5 fields). No structural
change needed, but confirm no dangling/empty cell.
Decide scope of the URL-param plumbing (see open questions) — likely leave intact
app/(portal)/history/page.tsx, lib/history-filter.ts, and
app/api/reports/export/route.ts so existing deep-links keep filtering.

Files / areas involved

app/(portal)/history/history-filters.tsx — the only file that must change (the filter UI).
Consumers of the approvedFrom/approvedTo params that should KEEP working (do not break):
- app/(portal)/dashboard/page.tsx:184 — "Approved This Month" card links to
  /history?approvedFrom=....
- app/(portal)/reports/accounting-codes/[id]/page.tsx:96 and
  reports/cost-centres/[id]/page.tsx:87 — "View POs" drill-downs append
  approvedFrom/approvedTo.
- app/(portal)/history/page.tsx, lib/history-filter.ts (buildPoHistoryWhere),
  app/api/reports/export/route.ts — read the params server-side, independent of the filter
  component. The deep-link filtering survives even after the input fields are gone.
- tests/staging/issue-32-approved-month-clickthrough.spec.ts — asserts only the dashboard
  card lands on /history?approvedFrom=... (URL + filtered results); it does not interact
  with the removed input, so it is unaffected.

Open questions

Keep the deep-link filtering? Recommended: yes — remove only the visible inputs and
leave page.tsx / history-filter.ts / export route reading approvedFrom/approvedTo, so
the dashboard card and report drill-downs continue to pre-filter History by approval date.
Fully ripping out the params would break those flows (and the #32 staging test) — out of
scope for "remove the search field".
Behavioural nuance: once the fields are gone, a user who arrives via a deep-link with
approvedFrom set and then clicks Apply on other filters will no longer re-carry the
approved-date params (they're dropped from buildParams). This is the expected consequence
of removing the field; flag if the manager actually wants the deep-linked filter preserved
on re-apply.

Routing rationale

Routing rationale: Localized single-file UI removal in a client component with clear acceptance (two fields gone, deep-links preserved), no DB/auth/payments/migrations, verifiable by type-check + lint → claude-queue.

Routing: claude-queue | Type: feature

## Claude triage # Triage — Issue #136: Remove the "Approved From" and "Approved To" search fields **Page:** `/history` (PO History) · **Priority:** P2 · **Raised by:** Kaushal Pal Singh (MANAGER) ## Interpretation The PO History filter bar currently exposes two date inputs — **"Approved From"** and **"Approved To"** — that filter POs by their approval date (`approvedAt`), in addition to the existing **From/To** (created-date) range. The manager considers these two fields unnecessary and wants them removed from the filter UI. This is a UI simplification: drop the two date pickers from the History filter form. The intent is the **visible search fields**, not necessarily the underlying URL-param machinery, which is also used by deep-links from elsewhere (see open questions). ## Action items 1. **`app/(portal)/history/history-filters.tsx`** (primary, client component) — remove: - The two `<div>` blocks rendering the **"Approved From"** and **"Approved To"** `<input type="date">` fields (lines ~115–124). - Their `approvedFrom` / `approvedTo` `useState` hooks (lines 39–40) and setter usages. - Their entries in `buildParams()` (lines 68–69), `clear()` (line 86), and the `hasFilters` check (line 93). 2. **Verify the grid still lays out cleanly** — the filter grid is `sm:grid-cols-4`; removing two cells leaves From, To, Cost Centre, Accounting Code, Status (5 fields). No structural change needed, but confirm no dangling/empty cell. 3. **Decide scope of the URL-param plumbing** (see open questions) — likely **leave intact** `app/(portal)/history/page.tsx`, `lib/history-filter.ts`, and `app/api/reports/export/route.ts` so existing deep-links keep filtering. ## Files / areas involved - `app/(portal)/history/history-filters.tsx` — the only file that must change (the filter UI). - **Consumers of the `approvedFrom`/`approvedTo` params that should KEEP working** (do not break): - `app/(portal)/dashboard/page.tsx:184` — "Approved This Month" card links to `/history?approvedFrom=...`. - `app/(portal)/reports/accounting-codes/[id]/page.tsx:96` and `reports/cost-centres/[id]/page.tsx:87` — "View POs" drill-downs append `approvedFrom`/`approvedTo`. - `app/(portal)/history/page.tsx`, `lib/history-filter.ts` (`buildPoHistoryWhere`), `app/api/reports/export/route.ts` — read the params server-side, independent of the filter component. The deep-link filtering survives even after the input fields are gone. - `tests/staging/issue-32-approved-month-clickthrough.spec.ts` — asserts only the dashboard card lands on `/history?approvedFrom=...` (URL + filtered results); it does **not** interact with the removed input, so it is unaffected. ## Open questions - **Keep the deep-link filtering?** Recommended: **yes** — remove only the visible inputs and leave `page.tsx` / `history-filter.ts` / export route reading `approvedFrom`/`approvedTo`, so the dashboard card and report drill-downs continue to pre-filter History by approval date. Fully ripping out the params would break those flows (and the #32 staging test) — out of scope for "remove the search field". - **Behavioural nuance:** once the fields are gone, a user who arrives via a deep-link with `approvedFrom` set and then clicks **Apply** on other filters will no longer re-carry the approved-date params (they're dropped from `buildParams`). This is the expected consequence of removing the field; flag if the manager actually wants the deep-linked filter preserved on re-apply. ## Routing rationale Routing rationale: Localized single-file UI removal in a client component with clear acceptance (two fields gone, deep-links preserved), no DB/auth/payments/migrations, verifiable by type-check + lint → claude-queue. **Routing:** `claude-queue` | **Type:** `feature`

shad0w added

claude-working

and removed

claude-queue

labels 2026-06-25 21:51:10 +00:00

shad0w commented

2026-06-25 21:51:11 +00:00

Author

Owner

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

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

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

2026-06-25 21:53:19 +00:00

fix: Remove the Approved From and Approved to search field #137

shad0w referenced this issue from a commit

2026-06-25 21:53:20 +00:00

feat(history): remove Approved From/To search fields

shad0w added

claude-pr

and removed

claude-working

labels 2026-06-25 21:53:20 +00:00

shad0w commented

2026-06-25 21:53:20 +00:00

Author

Owner

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

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

shad0w referenced this issue from a commit

2026-06-25 22:16:06 +00:00

test(history): cover removal of Approved From/To filters (#136)

shad0w closed this issue

2026-06-25 22:25:10 +00:00