Time logging and the timesheet
Time logging records how long work takes. This page covers worklogs, the timesheet, and the leave settings the timesheet reads.
Time logging is a per-project setting. A project administrator turns it on from Project settings → Time logging. Until then, an item shows no time controls: no estimate field, no Log work button, and no worklog list.
If you expect to log time on an item and cannot find the control, check
whether the project has time logging on. You need the project.manage
permission atom to turn it on.
An estimate is the time you expect an item to take. Set it from the item's Time tracking panel. The panel shows logged time against the estimate, and the remaining time (estimate minus logged) updates as worklogs land. An item with no estimate shows only what is logged.
You need the item.update permission atom to set or clear an estimate, and
the project must have time logging on.
Story points are a separate, also-optional setting. An administrator turns on Story points for an instance, or for one project, from Settings → General or the project's own settings. This adds a Points field to the item: a plain number from 0 to 999, in half-point steps. Points are not time. They are a separate size estimate, one the velocity and burnup reports can measure in instead of item counts. Points are off by default.
A worklog records:
-
Time — how long, entered as text (
2h 30m,1d,90m). - Date — the day the work happened. Defaults to today.
- Category — what kind of work it was. Optional on an item; required on a worklog with no item.
- Note — a free-text description (optional).
- Author — who logged it. Normally the person logging the time.
To log work on an item:
- Open the item and expand Time tracking.
- Click Log work.
- Enter the time spent. Add a date, category, or note if you want.
- Click Log work to save.
You need the worklog.write permission atom on the project.
To edit or remove a worklog, open its row in the item's Time tracking panel
and use the edit or delete icon. You can edit or remove your own worklogs.
A project manager (project.manage) can edit or remove anyone's worklog on
that project.
The item's Work log tab, next to Comments and History, shows the same worklogs read-only. It is a quick way to see the history without opening the editable panel.
The list of categories (Development, Investigation, Code Review, and so on)
is server-wide: one list serves every project. An administrator maintains
it from Settings → Time logging, under Work categories, with the
global.manage permission atom. To retire a category, archive it: an
archived category stays on old worklogs but drops out of the picker.
A worklog can exist with no item at all. Use this for meetings, admin time, and other general work that is not a specific issue. Click Log time on the timesheet to open the form.
An itemless worklog can name a project, or carry no project at all for time
that belongs to none. Its category is required: with no item, the category
is what identifies the entry everywhere it appears. You need worklog.write
on some project to log general time.
Open Timesheet to see logged time across the projects and people you have access to. Switch between Day, Week, and Month at the top. Use the arrows, or Today, to move through time.
Group the grid by issue, epic, person, or category. Click a row to expand it into the individual worklogs behind the total.
With the timesheet.view permission atom, you can filter by project, team,
or person, and see everyone's time. Without it, you see only your own
logged time, and no Team or Person filter appears: the timesheet reads
"Your timesheet" instead.
Group by person to see one row per human, with a cell for each day and a row total.
A cell's total is the sum of that person's worklogs on that calendar day, across every project the timesheet currently shows. A row's total sums its cells; a column's total sums that day across every row. Durations use the instance's hours-per-day setting: a figure like "1d 2h" is one working day (as configured) plus two hours, not one calendar day.
The timesheet carries its own SLQ filter bar in the top query slot, separate from the project, team, and person dropdowns. It compiles against the worklog dialect of SLQ, not the item dialect views use. Its rows are worklogs, so it can express things an item query cannot, such as a worklog with no item at all.
The worklog dialect's own fields are bare, the same convention item queries
use: author, category, worked_on, time, note, project, and
issue. issue is the one relational field, and it carries three forms:
-
issue IS EMPTY— worklogs with no item (general time). -
issue = RADD-1— worklogs logged against one specific item. -
issue.<anything>— handed to the item query language, so every item field (custom fields, labels, ancestors) is reachable from the timesheet.
Four real examples:
author = me AND issue.assignee != me
Your hours on issues assigned to someone else.
issue IS EMPTY AND category = "Code Review"
General worklogs, with no item, logged under Code Review.
issue.category = done AND worked_on >= 2026-08-01
Time logged since August 1 on items now in a done-category state.
time > 4h
Single worklogs longer than four hours.
A committed query narrows the rows the timesheet shows. It can only narrow
what you already see under the timesheet.view rule above; it can never
widen it.
On the By-person grid, a completed workday tints amber if it is under the minimum hours, and red if it is over the maximum. Two instance settings control the thresholds:
| Setting | What it does | Default |
|---|---|---|
| Minimum hours per workday | Below this on a workday, the day tints amber | 6 |
| Maximum hours per day | Above this on any day, the day tints red | 10 |
An administrator sets these from Settings → Time logging.
The tinting has exemptions:
- Today and future days. A day that has not finished yet is never judged — it would always read under the minimum, before the day is over.
- Non-working days. The under-logged check applies only on a day in the instance's working week (Settings → Time logging, Working days). A weekend showing 0h is not flagged.
- Leave and holiday days. A day covered by the person's own leave, or a team holiday, is exempt from both checks, and shows an "away" marker instead.
The over-logged (red) check applies on any finished day, working day or not — logging 12 hours on a Saturday still flags.
Leave is a period of absence: a person's own leave, or a team's public holiday. A person records their own leave from their Profile page. A team steward (an owner or manager of the team) can record leave for that team's members. An administrator records team holidays, from Settings → Time logging.
A holiday names a team, not a list of people. When the server reads a holiday, it expands to that team's current members. Someone who joins the team later is covered by a holiday defined before they joined; someone who leaves stops being covered. The server never snapshots membership onto the holiday record.
Everywhere a person's name or avatar appears, an away person shows dimmed and carries an "away" marker while their leave or holiday applies. This reaches the issue rail, the new-item modal, comment authors, and more — one shared indicator, not a timesheet-only feature.
On the timesheet, a day covered by leave or a holiday shows the "away" marker in place of the tinting above. It still shows any hours logged that day, but the server never judges it against the minimum or maximum.
TODO(verify): the exact list of surfaces the away indicator reaches, beyond the ones named above — confirmed in code but not exhaustively re-checked against the current UI for this page.
Mirrored from project.radd-hq.com on 2026-09-12. Documentation is written there; this copy is regenerated by scripts/publish_wiki.py and hand edits do not survive it.