feat(tickets): inline-edit status/priority/assignee on ticket detail #186
No reviewers
Labels
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
psa-systems/mokosh-apps!186
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/pms-359-ticket-inline-edit"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The ticket detail page only let a user edit the description. Status, priority, and assignee rendered as read-only badges. For a service-desk app that means a ticket created via the New Ticket form was effectively stuck in its initial state forever - no way to move it New -> In Progress -> Resolved, no way to reassign, no way to correct an off-by-one priority. Combined with the PMS-358 priority-drop bug (every ticket created with whatever the tenant default priority is), the workflow loop a PSA needs to do its job did not exist.
Three sidebar rows that used to render Badges (Status, Priority, Assigned To) now render Select editors bound to the tenant's lookup tables (GET /tickets/statuses, /tickets/priorities, /auth/users). Changing the value spawns a PUT /tickets/{id} with the matching field (status_id / priority_id / assigned_to_id - the server's UpdateTicketRequest already accepts all three), and on success restarts the ticket + history resources so the change-history pane records the edit alongside any prior description edits. Errors surface inline below the editors. While the lookups are still in flight, the Selects show a single "Loading…" placeholder so the page never collapses.
RemoteTicketDetail picks up assigned_to_id (the underlying field the editor binds to) and RemoteSummary picks up the status/priority id, both already present in the server's TicketResponse but never read until now. assigned_to_name and priority_badge_variant are dropped: the inline editors render the assignee name from the cached users list, and Status keeps its badge via the existing ticket_status_badge helper (priority no longer needs a badge variant on the detail page now that the Select shows the name directly).
#PMS-359
The ticket detail page only let a user edit the description. Status, priority, and assignee rendered as read-only badges. For a service-desk app that means a ticket created via the New Ticket form was effectively stuck in its initial state forever - no way to move it New -> In Progress -> Resolved, no way to reassign, no way to correct an off-by-one priority. Combined with the PMS-358 priority-drop bug (every ticket created with whatever the tenant default priority is), the workflow loop a PSA needs to do its job did not exist. Three sidebar rows that used to render Badges (Status, Priority, Assigned To) now render Select editors bound to the tenant's lookup tables (GET /tickets/statuses, /tickets/priorities, /auth/users). Changing the value spawns a PUT /tickets/{id} with the matching field (status_id / priority_id / assigned_to_id - the server's UpdateTicketRequest already accepts all three), and on success restarts the ticket + history resources so the change-history pane records the edit alongside any prior description edits. Errors surface inline below the editors. While the lookups are still in flight, the Selects show a single "Loading…" placeholder so the page never collapses. RemoteTicketDetail picks up assigned_to_id (the underlying field the editor binds to) and RemoteSummary picks up the status/priority id, both already present in the server's TicketResponse but never read until now. assigned_to_name and priority_badge_variant are dropped: the inline editors render the assignee name from the cached users list, and Status keeps its badge via the existing ticket_status_badge helper (priority no longer needs a badge variant on the detail page now that the Select shows the name directly). #PMS-3595da22cca12da022d06f7