MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-97

2.3.12 Collect a Due date in the create modal (mirror Jira; finding #56)

Done
Description

Estimate: 14m · Depends on: 2.3.11, 2.4.12

Add a Due date field to CreateIssueModal (2.3.3) using the shipped DatePicker (2.4.12), placed per the 2.3.11 design (after Priority). Collect the ISO YYYY-MM-DD in the modal's form state and pass it through createIssueAction → createWorkItem so a new issue persists its due date. Mirror Jira: Due date is optional/nullable at create.

Through the 4-layer path: confirm CreateWorkItemInput / createWorkItem accept dueDate; if not, thread it through (DTO → service → repository) — the work_item already HAS a dueDate column (the edit form writes it), so this is wiring the create path to the existing field, no schema change. UTC-safe conversion (the same ${date}T00:00:00.000Z the edit form + detail rail use). Resolves finding #56.

Done: PR #107 merged 2026-06-05, merge commit 68a34b1 — RE-CLOSES Story 2.3. Resolves finding #56 ("mirror Jira"): the create modal now collects an optional Due date via the shipped DatePicker, placed AFTER Priority per the 2.3.11 design. Held as the picker's YYYY-MM-DD value → converted to a UTC ISO string on submit (the same ${date}T00:00:00.000Z the edit form uses) → sent ONLY when set (plain-create payload unchanged, so the exact-match test stays green). createIssueAction's CreateIssueInput gained dueDate?, threaded to createWorkItem. Pure create-path wiring — the service/DTO/work_item.dueDate column already accepted dueDate (the edit form writes it; service-edge-cases.test.ts already covers create-with-dueDate at the service layer), so no schema/service/repo change (4-layer contract intact). New component test: choose Today → UTC ISO threaded; no-date create omits the key (Radix-Popover happy-dom polyfills). Assignee at create (in create.pen, never built — finding #51) left untouched. tsc/eslint/prettier clean, 112/112 component tests; real-PG create-with-dueDate covered in CI.

Acceptance criteria

  • The create modal shows a Due date field (DatePicker, after Priority) matching the 2.3.11 design; selecting a date is optional.
  • Creating an issue WITH a due date persists it (visible on the detail rail / edit form); creating WITHOUT one stores null — no off-by-one (UTC-safe).
  • createWorkItem accepts dueDate through the Route/Action → Service → Repository path (added if missing); no raw-Prisma shortcut.
  • Component test: create-with-due-date + create-without; existing create-modal tests stay green. tsc / eslint / prettier clean; next build compiles.

Context refs

  • app/(authed)/_components/CreateIssueModal.tsx — the modal to extend (type/parent/title/description/priority today)
  • app/(authed)/issues/actions.ts createIssueAction + createWorkItem service + CreateWorkItemInput DTO — the create path to thread dueDate through
  • components/ui/DatePicker (2.4.12) + how EditIssueForm (2.3.6) holds/converts dueDate
  • The 2.3.11 design asset (create-modal Due date) — the layout authority