shad0w commented

Owner

Raised by

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

Description

Provide list of Project Codes in drop down menu:

Petronet LNG Cochin
COMACOE Trombay
Haldia Reach
Haldia MMT
COMACOE Mandvi

Priority

P2 — Medium

Context

Page: /po/new
Reported at: 2026-06-24T07:50:59.312Z

### Raised by Kaushal Pal Singh (kps@pelagiamarine.com, MANAGER) — via portal Report Issue button ### Description Provide list of Project Codes in drop down menu: - Petronet LNG Cochin - COMACOE Trombay - Haldia Reach - Haldia MMT - COMACOE Mandvi ### Priority P2 — Medium ### Context - Page: `/po/new` - Reported at: 2026-06-24T07:50:59.312Z

shad0w added the

portal

label 2026-06-24 07:50:59 +00:00

shad0w added the

feature

claude-queue

triaged

labels 2026-06-24 08:01:18 +00:00

shad0w commented

2026-06-24 08:01:18 +00:00

Author

Owner

Claude triage

Triage — Issue #124: New PO Project Code Selection

Type: Feature (enhancement) · Priority: P2 · Page: /po/new
Routing: claude-queue

Request interpretation

The PO create form (/po/new) currently exposes Project Code as a free-text
optional input. The reporter (a Manager) wants it to be a drop-down restricted to a
known list of project codes:

Petronet LNG Cochin
COMACOE Trombay
Haldia Reach
Haldia MMT
COMACOE Mandvi

This is an enhancement to existing behaviour (free-text → constrained select), not a bug —
nothing is broken; the field works today.

Key finding — no schema change needed

projectCode already exists as a nullable column and is already wired end-to-end:

prisma/schema.prisma:560 — projectCode String? (already nullable, free text).
lib/validations/po.ts:36 — projectCode: z.string().optional().
Server actions already read it via formData.get("projectCode") (new / edit /
manager-edit) and persist ?? null.

So this is a UI-only change: swap the <input> for a <select> carrying the five
fixed options plus an empty "— none —" option (the field stays optional). No DB migration,
no permissions, no payments, no external systems.

Action items

Add a single shared source of truth for the codes, e.g. PROJECT_CODES in
lib/validations/po.ts (next to the existing PO constants like TC_DEFAULTS), so all
three forms import the same list and it is easy to extend later.
Replace the free-text Project Code input with a native <select name="projectCode">
(keeping name="projectCode" so the existing server actions need no change) in all
three PO forms:
- app/(portal)/po/new/new-po-form.tsx:163-164
- app/(portal)/po/[id]/edit/edit-po-form.tsx:199-200
- app/(portal)/approvals/[id]/manager-edit-po-form.tsx:197-198
  Include a blank/optional first option since the field is not required.
Edit / manager-edit value preservation: historical POs may hold a projectCode
that is not in the new list. Mirror the existing Delivery-Location pattern
(### Delivery Locations, App/CLAUDE.md): if po.projectCode is set but not in the
list, render it as a leading "(current)" option so it is never silently dropped.
(Optional, low-risk) tighten validation to z.enum([...PROJECT_CODES]).optional() in
lib/validations/po.ts:36. Defer if it would reject legacy values on edit — keeping
z.string().optional() is the safe default and still passes type-check.

Files / areas involved

app/(portal)/po/new/new-po-form.tsx
app/(portal)/po/[id]/edit/edit-po-form.tsx
app/(portal)/approvals/[id]/manager-edit-po-form.tsx
lib/validations/po.ts (shared PROJECT_CODES constant)
No changes needed in the three actions.ts files, schema.prisma, or po-detail.tsx.

Acceptance / verification

The three forms show a Project Code dropdown with exactly the five codes + an empty
option; selection persists and displays on PO detail (po-detail.tsx already renders it).
pnpm type-check and pnpm lint pass.
Existing PO unit/integration tests still pass (field name unchanged).

Open questions (non-blocking — sensible defaults chosen)

Hardcoded vs admin-managed list? Issue gives a fixed list of 5, so a hardcoded
shared constant is the proportionate choice. An admin-managed table (like sites /
delivery locations) would be a larger feature + migration — out of scope for this P2.
Default: hardcode.
Enforce enum at validation? Defaulting to leaving the field as optional string to
avoid rejecting legacy values on edit (see action item 4).

Routing rationale: localized UI-only change (free-text input → fixed-list select) on an
already-existing nullable column — no migration, auth, payments, or external systems —
with clear acceptance verifiable by type-check/lint/existing tests, so it routes to
claude-queue.

Routing: claude-queue | Type: feature

## Claude triage # Triage — Issue #124: New PO Project Code Selection **Type:** Feature (enhancement) · **Priority:** P2 · **Page:** `/po/new` **Routing:** claude-queue ## Request interpretation The PO create form (`/po/new`) currently exposes **Project Code** as a free-text optional input. The reporter (a Manager) wants it to be a **drop-down** restricted to a known list of project codes: - Petronet LNG Cochin - COMACOE Trombay - Haldia Reach - Haldia MMT - COMACOE Mandvi This is an enhancement to existing behaviour (free-text → constrained select), not a bug — nothing is broken; the field works today. ## Key finding — no schema change needed `projectCode` **already exists** as a nullable column and is already wired end-to-end: - `prisma/schema.prisma:560` — `projectCode String?` (already nullable, free text). - `lib/validations/po.ts:36` — `projectCode: z.string().optional()`. - Server actions already read it via `formData.get("projectCode")` (new / edit / manager-edit) and persist `?? null`. So this is a **UI-only** change: swap the `<input>` for a `<select>` carrying the five fixed options plus an empty "— none —" option (the field stays optional). No DB migration, no permissions, no payments, no external systems. ## Action items 1. Add a single shared source of truth for the codes, e.g. `PROJECT_CODES` in `lib/validations/po.ts` (next to the existing PO constants like `TC_DEFAULTS`), so all three forms import the same list and it is easy to extend later. 2. Replace the free-text Project Code input with a native `<select name="projectCode">` (keeping `name="projectCode"` so the existing server actions need no change) in all **three** PO forms: - `app/(portal)/po/new/new-po-form.tsx:163-164` - `app/(portal)/po/[id]/edit/edit-po-form.tsx:199-200` - `app/(portal)/approvals/[id]/manager-edit-po-form.tsx:197-198` Include a blank/optional first option since the field is not required. 3. **Edit / manager-edit value preservation:** historical POs may hold a `projectCode` that is not in the new list. Mirror the existing Delivery-Location pattern (`### Delivery Locations`, App/CLAUDE.md): if `po.projectCode` is set but not in the list, render it as a leading "(current)" option so it is never silently dropped. 4. (Optional, low-risk) tighten validation to `z.enum([...PROJECT_CODES]).optional()` in `lib/validations/po.ts:36`. Defer if it would reject legacy values on edit — keeping `z.string().optional()` is the safe default and still passes type-check. ## Files / areas involved - `app/(portal)/po/new/new-po-form.tsx` - `app/(portal)/po/[id]/edit/edit-po-form.tsx` - `app/(portal)/approvals/[id]/manager-edit-po-form.tsx` - `lib/validations/po.ts` (shared `PROJECT_CODES` constant) - No changes needed in the three `actions.ts` files, `schema.prisma`, or `po-detail.tsx`. ## Acceptance / verification - The three forms show a Project Code dropdown with exactly the five codes + an empty option; selection persists and displays on PO detail (`po-detail.tsx` already renders it). - `pnpm type-check` and `pnpm lint` pass. - Existing PO unit/integration tests still pass (field name unchanged). ## Open questions (non-blocking — sensible defaults chosen) - **Hardcoded vs admin-managed list?** Issue gives a fixed list of 5, so a hardcoded shared constant is the proportionate choice. An admin-managed table (like sites / delivery locations) would be a larger feature + migration — out of scope for this P2. Default: hardcode. - **Enforce enum at validation?** Defaulting to leaving the field as optional string to avoid rejecting legacy values on edit (see action item 4). Routing rationale: localized UI-only change (free-text input → fixed-list select) on an already-existing nullable column — no migration, auth, payments, or external systems — with clear acceptance verifiable by type-check/lint/existing tests, so it routes to claude-queue. **Routing:** `claude-queue` | **Type:** `feature`

shad0w added

claude-working

and removed

claude-queue

labels 2026-06-24 08:02:45 +00:00

shad0w commented

2026-06-24 08:02:45 +00:00

Author

Owner

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

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

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

2026-06-24 08:06:10 +00:00

fix: New PO Project Code Selection #126

shad0w added

claude-pr

and removed

claude-working

labels 2026-06-24 08:06:11 +00:00

shad0w commented

2026-06-24 08:06:11 +00:00

Author

Owner

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

[Claude] Opened PR [#126](https://git.pelagiamarine.com/shad0w/pelagia-portal/pulls/126) 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 08:06:12 +00:00

feat(po): Project Code dropdown on PO forms

Rows
Columns

[Issue]: New PO Project Code Selection #124

Raised by

Description

Priority

Context

Claude triage

Triage — Issue #124: New PO Project Code Selection

Request interpretation

Key finding — no schema change needed

Action items

Files / areas involved

Acceptance / verification

Open questions (non-blocking — sensible defaults chosen)