shad0w commented

Owner

Raised by

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

Description

Similar to items, vendors should also have a search that searches through names and codes

Priority

P2 — Medium

Context

Page: /dashboard
Reported at: 2026-06-23T23:31:19.302Z

### Raised by Kaushal Pal Singh (kps@pelagiamarine.com, MANAGER) — via portal Report Issue button ### Description Similar to items, vendors should also have a search that searches through names and codes ### Priority P2 — Medium ### Context - Page: `/dashboard` - Reported at: 2026-06-23T23:31:19.302Z

shad0w added the

portal

label 2026-06-23 23:31:19 +00:00

shad0w added the

feature

claude-queue

triaged

labels 2026-06-23 23:42:07 +00:00

shad0w commented

2026-06-23 23:42:07 +00:00

Author

Owner

Claude triage

Triage — Issue #109: On new PO screen Vendors should have search

Raised by: Kaushal Pal Singh (kps@pelagiamarine.com, MANAGER)
Priority: P2 — Medium
Type: Feature (enhancement to existing UI behaviour)
Routing: claude-queue

Interpretation

On the new-PO screen the Vendor field is a plain native <select> dropdown with no
search — the user must scroll the full vendor list. Items, by contrast, use a search-driven
autocomplete. The request is to give Vendor the same searchable behaviour, matching against
both the vendor name and the vendor code (vendorId).

The good news: unlike items (which hit /api/products/search), the vendor list is already
loaded client-side and passed into the form as a vendors prop. So the search can be a
pure client-side filter on the in-memory list — no new API route, no DB work, no schema
migration.

Action items

Replace the native vendor <select> with a searchable combobox in
app/(portal)/po/new/new-po-form.tsx (lines ~225–246, the "Vendor (optional…)" section).
- Filter the existing vendors array case-insensitively by name and vendorId
  (the formal code). Preserve current behaviour: optional field, a "No vendor selected"
  empty option, and the existing label format "{name} (CODE)" / "(unverified)".
- Submit must still post a hidden name="vendorId" input so the server action is unchanged.
Choose the combobox approach (see open questions): either
(a) generalize the existing components/ui/searchable-select.tsx to accept a generic
option list (it is currently typed to AccountGroup / code+name groups), or
(b) add a small dedicated vendor combobox component mirroring its look/behaviour
(trigger button + search input + filtered list, portal-rendered, close-on-outside-click).
Apply consistently across the other PO forms that have the identical vendor select, so
the experience matches (see open question on scope):
- app/(portal)/po/[id]/edit/edit-po-form.tsx
- app/(portal)/approvals/[id]/manager-edit-po-form.tsx
Add/extend unit tests for the filter logic (matches by name, matches by code,
case-insensitive, empty-query shows all, "No vendor selected" still selectable).
Verify with pnpm type-check, pnpm lint, pnpm test.

Files / areas involved

app/(portal)/po/new/new-po-form.tsx — primary target (the issue's "new PO screen").
app/(portal)/po/[id]/edit/edit-po-form.tsx, app/(portal)/approvals/[id]/manager-edit-po-form.tsx — same vendor select pattern (consistency).
components/ui/searchable-select.tsx — existing reusable combobox to reuse/generalize.
components/po/po-line-items-editor.tsx — reference for the item-search UX being mirrored.
Vendor data model (prisma/schema.prisma): Vendor.name + Vendor.vendorId (the code) — read-only reference, no migration.
tests/unit/ — new/updated test for the vendor filter.

Open questions (non-blocking; safe defaults exist)

Scope: issue names only the "new PO screen". Default to applying it there, and extend
to the edit + manager-edit forms for consistency (low risk, same pattern). Reviewer can
trim if they want new-PO only.
Reuse vs. new component: SearchableSelect is currently account-code specific. Default
to a small dedicated vendor combobox (or a light generalization) rather than overloading the
account type — implementer's discretion.
Code matching field: match on vendorId (the formal verified code shown in the label).
Unverified vendors have a null code, so they remain findable by name only.

Why claude-queue

Localized client-side UI change with a clear acceptance criterion ("search by name and code"),
an existing in-repo pattern to mirror, and verifiable via type-check / lint / unit tests. It
touches no DB migrations, auth/permissions, payments, or external systems, and needs no new
API (vendor list is already client-side). It is not a large multi-file feature.

Routing rationale: A localized, client-side searchable-dropdown enhancement with clear acceptance and existing patterns, verifiable by type-check/lint/unit tests and touching no DB/auth/payments/external systems → claude-queue.

Routing: claude-queue | Type: feature

## Claude triage # Triage — Issue #109: On new PO screen Vendors should have search **Raised by:** Kaushal Pal Singh (kps@pelagiamarine.com, MANAGER) **Priority:** P2 — Medium **Type:** Feature (enhancement to existing UI behaviour) **Routing:** claude-queue ## Interpretation On the new-PO screen the **Vendor** field is a plain native `<select>` dropdown with no search — the user must scroll the full vendor list. Items, by contrast, use a search-driven autocomplete. The request is to give Vendor the same searchable behaviour, matching against both the vendor **name** and the vendor **code** (`vendorId`). The good news: unlike items (which hit `/api/products/search`), the vendor list is **already loaded client-side and passed into the form as a `vendors` prop**. So the search can be a pure client-side filter on the in-memory list — **no new API route, no DB work, no schema migration**. ## Action items 1. **Replace the native vendor `<select>` with a searchable combobox** in `app/(portal)/po/new/new-po-form.tsx` (lines ~225–246, the "Vendor (optional…)" section). - Filter the existing `vendors` array case-insensitively by `name` **and** `vendorId` (the formal code). Preserve current behaviour: optional field, a "No vendor selected" empty option, and the existing label format `"{name} (CODE)"` / `"(unverified)"`. - Submit must still post a hidden `name="vendorId"` input so the server action is unchanged. 2. **Choose the combobox approach** (see open questions): either (a) generalize the existing `components/ui/searchable-select.tsx` to accept a generic option list (it is currently typed to `AccountGroup` / code+name groups), or (b) add a small dedicated vendor combobox component mirroring its look/behaviour (trigger button + search input + filtered list, portal-rendered, close-on-outside-click). 3. **Apply consistently across the other PO forms** that have the identical vendor select, so the experience matches (see open question on scope): - `app/(portal)/po/[id]/edit/edit-po-form.tsx` - `app/(portal)/approvals/[id]/manager-edit-po-form.tsx` 4. **Add/extend unit tests** for the filter logic (matches by name, matches by code, case-insensitive, empty-query shows all, "No vendor selected" still selectable). 5. Verify with `pnpm type-check`, `pnpm lint`, `pnpm test`. ## Files / areas involved - `app/(portal)/po/new/new-po-form.tsx` — primary target (the issue's "new PO screen"). - `app/(portal)/po/[id]/edit/edit-po-form.tsx`, `app/(portal)/approvals/[id]/manager-edit-po-form.tsx` — same vendor select pattern (consistency). - `components/ui/searchable-select.tsx` — existing reusable combobox to reuse/generalize. - `components/po/po-line-items-editor.tsx` — reference for the item-search UX being mirrored. - Vendor data model (`prisma/schema.prisma`): `Vendor.name` + `Vendor.vendorId` (the code) — **read-only reference, no migration**. - `tests/unit/` — new/updated test for the vendor filter. ## Open questions (non-blocking; safe defaults exist) - **Scope:** issue names only the "new PO screen". Default to applying it there, and extend to the edit + manager-edit forms for consistency (low risk, same pattern). Reviewer can trim if they want new-PO only. - **Reuse vs. new component:** `SearchableSelect` is currently account-code specific. Default to a small dedicated vendor combobox (or a light generalization) rather than overloading the account type — implementer's discretion. - **Code matching field:** match on `vendorId` (the formal verified code shown in the label). Unverified vendors have a null code, so they remain findable by name only. ## Why claude-queue Localized client-side UI change with a clear acceptance criterion ("search by name and code"), an existing in-repo pattern to mirror, and verifiable via type-check / lint / unit tests. It touches **no** DB migrations, auth/permissions, payments, or external systems, and needs no new API (vendor list is already client-side). It is not a large multi-file feature. Routing rationale: A localized, client-side searchable-dropdown enhancement with clear acceptance and existing patterns, verifiable by type-check/lint/unit tests and touching no DB/auth/payments/external systems → claude-queue. **Routing:** `claude-queue` | **Type:** `feature`

shad0w added

claude-working

and removed

claude-queue

labels 2026-06-23 23:42:07 +00:00

shad0w commented

2026-06-23 23:42:07 +00:00

Author

Owner

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

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

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

2026-06-23 23:47:11 +00:00

fix: On new PO screen Vendors should have search #110

shad0w added

claude-pr

and removed

claude-working

labels 2026-06-23 23:47:12 +00:00

shad0w commented

2026-06-23 23:47:12 +00:00

Author

Owner

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

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

shad0w referenced this issue from a commit

2026-06-23 23:47:13 +00:00

feat(po): make vendor field a searchable combobox

shad0w closed this issue

2026-06-23 23:52:48 +00:00

Rows
Columns

[Issue]: On new PO screen Vendors should have search #109

Raised by

Description

Priority

Context

Claude triage

Triage — Issue #109: On new PO screen Vendors should have search

Interpretation

Action items

Files / areas involved

Open questions (non-blocking; safe defaults exist)

Why claude-queue