fix(tickets): send priority_id on New Ticket create (was dropped silently) #185

Merged

YousifShkara merged 1 commit from fix/pms-358-ticket-priority-not-sent into main

2026-06-16 06:26:27 +02:00

YousifShkara commented

2026-06-16 06:26:24 +02:00

Owner

The New Ticket form had a Priority Select wired to a priority signal initialized to "medium", but the submit handler never read it - the POST body only carried title, description, company_id. Every ticket created via the form fell through to the tenant's default priority server-side, which is almost always Medium regardless of what the user picked. Reviewer (Claude for Chrome) reproduced: selecting High persists Medium on detail, list, dashboard, and the Open Tickets by Priority widget.

Doubly wrong because the server's CreateTicketRequest takes priority_id: Option, not a string name. Even if the submit handler had read the signal, sending "medium" as priority_id would have been silently coerced to None.

Fix lands the proper lookup: the form fetches GET /tickets/priorities on mount (paginated lookup the server has had all along), seeds the signal with whichever row carries is_default = true (or the first row), renders the Select with each priority's UUID as the option value and its name as the label, and serialises the chosen UUID as priority_id in the POST body. Empty signal (still fetching) sends None and lets the server's default apply.

The same fetch + UUID pattern will be reused by PMS-359 (inline edit on ticket detail). RemoteTicketPriority is exported at file scope so the detail page can grab it without re-declaring.

#PMS-358

The New Ticket form had a Priority Select wired to a `priority` signal initialized to "medium", but the submit handler never read it - the POST body only carried title, description, company_id. Every ticket created via the form fell through to the tenant's default priority server-side, which is almost always Medium regardless of what the user picked. Reviewer (Claude for Chrome) reproduced: selecting High persists Medium on detail, list, dashboard, and the Open Tickets by Priority widget. Doubly wrong because the server's CreateTicketRequest takes priority_id: Option<Uuid>, not a string name. Even if the submit handler had read the signal, sending "medium" as priority_id would have been silently coerced to None. Fix lands the proper lookup: the form fetches GET /tickets/priorities on mount (paginated lookup the server has had all along), seeds the signal with whichever row carries is_default = true (or the first row), renders the Select with each priority's UUID as the option value and its name as the label, and serialises the chosen UUID as priority_id in the POST body. Empty signal (still fetching) sends None and lets the server's default apply. The same fetch + UUID pattern will be reused by PMS-359 (inline edit on ticket detail). RemoteTicketPriority is exported at file scope so the detail page can grab it without re-declaring. #PMS-358

YousifShkara self-assigned this

2026-06-16 06:26:24 +02:00

YousifShkara added 1 commit

2026-06-16 06:26:24 +02:00

fix(tickets): send priority_id on New Ticket create (was dropped silently)

Create release / Create release from merged PR (pull_request) Has been skipped

Details

Check / clippy + fmt + tests (pull_request) Successful in 1m5s

Details

9e9d1993b3

The New Ticket form had a Priority Select wired to a `priority` signal initialized to "medium", but the submit handler never read it - the POST body only carried title, description, company_id. Every ticket created via the form fell through to the tenant's default priority server-side, which is almost always Medium regardless of what the user picked. Reviewer (Claude for Chrome) reproduced: selecting High persists Medium on detail, list, dashboard, and the Open Tickets by Priority widget.

Doubly wrong because the server's CreateTicketRequest takes priority_id: Option<Uuid>, not a string name. Even if the submit handler had read the signal, sending "medium" as priority_id would have been silently coerced to None.

Fix lands the proper lookup: the form fetches GET /tickets/priorities on mount (paginated lookup the server has had all along), seeds the signal with whichever row carries is_default = true (or the first row), renders the Select with each priority's UUID as the option value and its name as the label, and serialises the chosen UUID as priority_id in the POST body. Empty signal (still fetching) sends None and lets the server's default apply.

The same fetch + UUID pattern will be reused by PMS-359 (inline edit on ticket detail). RemoteTicketPriority is exported at file scope so the detail page can grab it without re-declaring.

#PMS-358

YousifShkara merged commit d7e9132123 into main

2026-06-16 06:26:27 +02:00

YousifShkara deleted branch fix/pms-358-ticket-priority-not-sent

2026-06-16 06:26:27 +02:00

YousifShkara referenced this pull request from a commit

2026-06-16 06:26:29 +02:00

Merge pull request 'fix(tickets): send priority_id on New Ticket create (was dropped silently)' (#185) from fix/pms-358-ticket-priority-not-sent into main

YousifShkara referenced this pull request from a commit

2026-06-16 07:56:58 +02:00

chore(ci): trigger image rebuild + :latest retag after Tier S merges

YousifShkara referenced this pull request

2026-06-16 07:57:45 +02:00