psa-systems/mokosh-server
Watch
9
0
Fork
You've already forked mokosh-server
 1
Code Issues Pull requests Projects Releases 10 Packages Wiki Activity Actions

feat(projects): accept actual_end_date on create for edit-form parity #278

Merged
vas2000-work merged 1 commit from feat/pms-361-create-project-symmetry into main 2026-06-16 23:49:37 +02:00
Conversation 0 Commits 1 Files changed 3 +77 -2
David commented 2026-06-16 18:48:31 +02:00
Owner
Copy link

The New Project form is meant to expose the same status/date/manager fields the Edit form does, so a project can be created in a non-default state in one submission instead of "create then edit" (PMS-361 finding #4). The server side already accepted status, project_manager_id, start_date and target_end_date on POST /projects and persisted them; the one CreateProjectRequest field UpdateProjectRequest had that Create lacked was actual_end_date.

Add actual_end_date to CreateProjectRequest and thread it through the create_project INSERT so the create DTO is fully symmetric with the update DTO. The "planning" status default is unchanged, so a create with no override still matches today's behaviour.

Add an integration test (create_accepts_status_dates_and_manager) proving the AC3 round-trip: a project created with status=active, a project manager, start_date, target_end_date and actual_end_date lands in the row and reads back on the detail endpoint, and that omitting status keeps the "planning" default.

Create-vs-Edit asymmetry audit (server DTOs):

  • projects: only actual_end_date was missing from Create; now closed.
  • tickets: CreateTicketRequest vs UpdateTicketRequest are field-symmetric (status/priority/assignee/dates all settable on create); no server gap (PMS-358 is a client-form drop, not a DTO omission).
  • tasks: CreateTaskRequest covers every UpdateTaskRequest field except sort_order reordering, which is create-time positional only; no functional gap.
  • companies/contacts/contracts: create DTOs already accept the same mutable fields their update DTOs expose.

#PMS-361

The New Project form is meant to expose the same status/date/manager fields the Edit form does, so a project can be created in a non-default state in one submission instead of "create then edit" (PMS-361 finding #4). The server side already accepted status, project_manager_id, start_date and target_end_date on POST /projects and persisted them; the one CreateProjectRequest field UpdateProjectRequest had that Create lacked was actual_end_date. Add actual_end_date to CreateProjectRequest and thread it through the create_project INSERT so the create DTO is fully symmetric with the update DTO. The "planning" status default is unchanged, so a create with no override still matches today's behaviour. Add an integration test (create_accepts_status_dates_and_manager) proving the AC3 round-trip: a project created with status=active, a project manager, start_date, target_end_date and actual_end_date lands in the row and reads back on the detail endpoint, and that omitting status keeps the "planning" default. Create-vs-Edit asymmetry audit (server DTOs): - projects: only actual_end_date was missing from Create; now closed. - tickets: CreateTicketRequest vs UpdateTicketRequest are field-symmetric (status/priority/assignee/dates all settable on create); no server gap (PMS-358 is a client-form drop, not a DTO omission). - tasks: CreateTaskRequest covers every UpdateTaskRequest field except sort_order reordering, which is create-time positional only; no functional gap. - companies/contacts/contracts: create DTOs already accept the same mutable fields their update DTOs expose. #PMS-361
feat(projects): accept actual_end_date on create for edit-form parity
All checks were successful
E2E / Playwright against staging (pull_request) Successful in 1m9s
Details
Check / fmt + clippy + compile + unit/doc tests (pull_request) Successful in 2m15s
Details
Integration / integration tests (pull_request) Successful in 5m55s
Details
Create release / Create release from merged PR (pull_request) Has been skipped
Details
5ac383a059 
The New Project form is meant to expose the same status/date/manager fields the Edit form does, so a project can be created in a non-default state in one submission instead of "create then edit" (PMS-361 finding #4). The server side already accepted status, project_manager_id, start_date and target_end_date on POST /projects and persisted them; the one CreateProjectRequest field UpdateProjectRequest had that Create lacked was actual_end_date.

Add actual_end_date to CreateProjectRequest and thread it through the create_project INSERT so the create DTO is fully symmetric with the update DTO. The "planning" status default is unchanged, so a create with no override still matches today's behaviour.

Add an integration test (create_accepts_status_dates_and_manager) proving the AC3 round-trip: a project created with status=active, a project manager, start_date, target_end_date and actual_end_date lands in the row and reads back on the detail endpoint, and that omitting status keeps the "planning" default.

Create-vs-Edit asymmetry audit (server DTOs):
- projects: only actual_end_date was missing from Create; now closed.
- tickets: CreateTicketRequest vs UpdateTicketRequest are field-symmetric (status/priority/assignee/dates all settable on create); no server gap (PMS-358 is a client-form drop, not a DTO omission).
- tasks: CreateTaskRequest covers every UpdateTaskRequest field except sort_order reordering, which is create-time positional only; no functional gap.
- companies/contacts/contracts: create DTOs already accept the same mutable fields their update DTOs expose.

#PMS-361
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
psa-systems/mokosh-server!278
No description provided.