Entry lifecycle
Every time entry in TAB lives in exactly one of five statuses, enforced by a database CHECK constraint: running, stopped, submitted, approved, locked. The status controls who can change it and where it shows up.
The five statuses
Running
The timer is ticking right now. The entry has a started_at but no ended_at. At most one running entry per user at any moment, enforced by a partial unique index in the schema, you can't have two running entries even if you try.
Next move: you stop it (from the dashboard banner). The entry becomes stopped.
Stopped
A complete entry with a start and an end. You own it. You can edit the start/end times and the notes, or delete the entry outright. It hasn't been seen by your manager yet.
Next move: you select it on Time entries and click Submit for approval. It becomes submitted. Manager rejections also land entries back here, with a rejection reason attached.
Submitted
You've handed it to a manager. The entry is read-only for you, no Submit or Delete action in the row's ⋯ menu, and the edit modal is closed to accountants. It sits in the Approvals queue.
Next move: the manager approves (becomes approved) or rejects (becomes stopped again, with a rejection_reason and rejected_at).
Approved
A manager has signed off. The entry counts as billable time and appears on the Unbilled report. Still read-only from your end, only admins can edit an approved entry, and only with a required reason.
Next move: admin locks the entry as part of a billing run. It becomes locked.
Locked
The entry is part of a closed billing period. Nobody edits a locked entry through the normal UI, not the owner, not the manager, not an admin. The backend explicitly rejects edits on locked entries.
Next move: none. The lifecycle ends here.
Common transitions
| From | To | Action | Who |
|---|---|---|---|
| running | stopped | Stop the timer | The owner |
| stopped | submitted | Submit (single or bulk) | The owner |
| submitted | approved | Approve | Manager / admin |
| submitted | stopped | Reject (with required reason) | Manager / admin |
| approved | locked | Lock | Admin |
The happy path is top-to-bottom: running → stopped → submitted → approved → locked. The only backwards step is a manager rejection.
Edits don't change the status
Editing an entry, changing the start/end times or notes, never moves it to a different status. A stopped entry stays stopped; a submitted entry stays submitted. Edits just set the was_edited flag and write audit rows.
Why this projects
- Trust. Once a manager approves, neither the staffer nor the manager can quietly adjust the entry. Only an admin can, and the change is audited.
- Billing accuracy. Locked entries can't drift. The number admin pulled for last quarter's invoices is the same number that's in the database today.
As an accountant your job is mostly the first two states: get entries from running to stopped cleanly, tidy them up, and submit. Everything from submitted onwards is somebody else's queue.