Approval

Returns project-days and project-weeks that have non-approved time entries, restricted to projects the caller is project lead on. Used to surface "to do" items in the approval inbox. Looks back six months (or to the account's approval-active date, whichever is later). Returns 403 if the caller leads no projects, or if approval is not active on the account.

Returns user-days and user-weeks where worktime entries are submitted but not yet approved, restricted to teams the caller has canApproveTeamWorktime for. Excludes freelancers (whose worktime isn't subject to this approval flow). Looks back six months.

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.

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 worktime can be moved between those states; not-yet-submitted worktime is ignored. When the new status is APPROVED, approvedBy and approvedOn are stamped; otherwise both are cleared. Permissions: canManageUsers for any user, or canApproveTeamWorktime covering a team the target user belongs to. Does not touch WORK or BREAK entries and does not affect ProjectDay records. Per-entry failures are collected into errors rather than aborting the batch.

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.

Returns a per-project map of weekly approval roll-ups (counts of submitted / approved / rejected / not-submitted entries plus project-day approval status). Admins (canManageAllProjects) see every project; others see only projects they are PM of, plus weeks belonging to teams they manage.

Advances the caller's NOTSUBMITTED and REJECTED WORK time entries on the given day to SUBMITTED. Running entries are stopped first. If worktime tracking is active on the account and no SUBMITTED/APPROVED WORKTIME entry exists for the day, one is created from the user's default start/end (or a zero-duration record on a non-working day) and submitted. Scoped to the caller — there is no way to submit on behalf of another user.

Returns a {userId: {day: {tracked, submitted}}} map. tracked is true if the user has any time entry on that day; submitted is true if all entries are submitted. Admins (canManageAllProjects) see all active users; others see users assigned to projects they are PM of. Window must be at most a week.

For each requested user, returns whether their WORKTIME and BREAK entries on each day of a date range meet labor-law compliance rules. Currently hard-coded to German rules (no per-user country handling yet): worktime is compliant when (worktime hours − break hours) >= expectedHours for the day; breaks are compliant when total break duration meets the legal minimum for the worked duration (no minimum below 6h, 30min for 6–9h, 45min above 9h). Date range capped at 7 days. Worktime entries with status NOTSUBMITTED or APPROVED are skipped during evaluation, which makes those days appear compliant. Permissions: canManageUsers or isRootAdmin for any user; otherwise canApproveTeamWorktime covering a team the target user belongs to. Users the caller is not allowed to see are silently dropped from the response.