change_approval_status
ChatGPTApprove, reject, or change submission status of time entries — and lock/unlock project days. Three input shapes; variant is chosen by which fields you supply: • Single entry —
timeEntryId + validationStatus. Granular state change for one entry, with optional field patches, break patches, and rejection/resubmission email. • Bulk WORK across dates — dates (≤7) + projectId and/or userId + teStatus and/or dayStatus. Approves submitted entries and/or locks days. Locking a day blocks further WORK entry creation on that (project, date) by any user — independent of whether the date is past, present, or future, and the day need not have any entries. Locking only happens when projectId is set without userId (scoping by user keeps the day open to others). • Bulk WORKTIME — userId + startDate + endDate + status. WORKTIME-only, range ≤7 days. ▸ POST /v1/approval/change-status Approve, reject, or re-submit a single time entry Changes one time entry's validationStatus and, optionally, patches its fields and sibling break entries in the same call. If the entry's ProjectDay is APPROVED and the new status is not APPROVED, the ProjectDay is automatically unlocked (set to NOTAPPROVED with approvedBy / approvedOn cleared) — only a PM of the project may trigger this. Permissions: an owner may submit their own entry; PMs of the entry's project may approve/reject WORK entries; users with canApproveTeamWorktime over the entry owner's team may approve/reject WORKTIME and BREAK entries. Running entries are rejected. Rejection (sendRejectionEmail) and re-submission (sendResubmissionEmail) notifications are sent asynchronously and do not block the response. ▸ POST /v1/approval/bulk-approve Approve / unapprove time entries and lock / unlock project days across up to seven days Performs two related actions in one call. This is the canonical endpoint for approving or unapproving project days — direct CRUD on /v1/project-days is not supported. - Approving time entries (retrospective): sets validationStatus: APPROVED on existing WORK entries that have already been submitted. - Locking project days (write-blocking): an APPROVED ProjectDay closes that (project, date) to all further WORK entry creation by any user until it is unlocked — this is the gate, not a side effect of approving entries. ProjectDay records may be locked on dates with zero existing time entries; this is the right way to close any period (past, present, or future) to new tracking without affecting any existing work. Invariant: an APPROVED ProjectDay means every WORK entry on that day is also APPROVED. There is no separate "approve the entries first, then approve the day" path — this endpoint is that path. Passing dayStatus: APPROVED together with teStatus: APPROVED both approves the day's submitted entries and locks the day in one shot. (Days with zero entries trivially satisfy the invariant and are still locked.) Two parameter modes: - Single-status (`validationStatus`): sets dayStatus to validationStatus; teStatus defaults to APPROVED when approving, SUBMITTED otherwise. - Split (`teStatus` + `dayStatus`): control the two independently within the invariant above. To lock a day, pass both as APPROVED. Constraints: dates capped at 7. At least one of projectId and userId must be set. ProjectDay locking only happens when projectId is set without userId (scoping by a single user does not lock the day, since other users may still need to track to it). Operates on WORK entries only. Permissions are checked per project: only PMs of a project may approve / unlock that project's days. Per-day and per-TE errors are collected into dayErrors rather than aborting the batch. ▸ POST /v1/approval/bulk-approve-worktime Bulk-change validationStatus on a user's worktime entries across a date range Bulk-updates validationStatus on a single user's WORKTIME entries across a date range of up to seven days. Only entries already past NOTSUBMITTED are affected — submitted, approved, and rejected w…





