Issue settings
Issue settings configure how work items behave everywhere on the server — their fields, links, labels, cycles, and time logs. This page documents each section field by field.
Open Settings → Fields. The page has two parts: your custom fields, and the builtin fields every item already carries.
Click New field to define one. Every field has a type:
| Field type | Holds |
|---|---|
| Text | Free text. |
| Number | A number. |
| Boolean | True or false. |
| Date | A calendar date. |
| Select | One value from a list of options. |
| Multi-select | Any number of values from a list of options. |
| User | A person. |
| URL | A web address. |
| Duration | A whole number of minutes. |
A field can be marked required. A select or multi-select field also carries a list of options and, optionally, a default value the server seeds onto a new item when you leave the field blank at create.
Adding an option is always safe. Removing one asks where the items that hold it should go first. A multi-select field drops the option from each item's list. A required select field needs a replacement value. An optional select field may clear instead.
The server does not offer a rename. Every saved view, automation, and form that names the old value would keep compiling and match nothing.
Available on sets the field's scope: no projects selected means the field is global and exists everywhere. Select one or more projects to scope it — the field then exists only there and vanishes elsewhere. This controls where the field exists. Who may read or write it where it exists is a separate question, answered by Restricted on below.
Restricted on adds read and write grants to a role, a team, a person, or a directory group. Scope each grant globally or to specific projects. With no grants, the field is open. Anyone who can read the item sees it, and anyone who can edit the item sets it. A read grant restricts who can see the field to the listed subjects. A write grant restricts who can change it — and a person who can write a field can always read it too. Project managers always pass, regardless of grants.
You need the field.manage permission atom, held on a project the field
covers, to manage that field.
Every item carries fields such as state, assignee, and priority without you defining them. Expand a builtin field's Grants row to add the same kind of read and write grant a custom field takes.
Title, state, and priority accept only write grants. A list or a board identifies its rows by these fields, so hiding them would break the surfaces that show them. Every other builtin field accepts both read and write grants.
If you cannot write a field, the item editor disables it up front and shows the reason on hover. It never waits for you to save and fail.
Open Settings → Link types. A link type describes how two items relate.
Four link types are built in:
- Blocks — directed: "blocks" / "is blocked by".
- Relates — symmetric: "relates to", the same both ways.
- Duplicates — directed: "duplicates" / "is duplicated by".
-
Mentions — directed and automatic. A
#-mention creates it. It is never offered as a manual choice.
Click New link type to define one. Fill in:
- A name and a stable, lowercase key — the key is permanent once created.
- A direction: directed reads differently each way; symmetric reads the same both ways.
- An outward name, and, for a directed type, an inward name.
- A scope: leave it empty for a global type offered on every project, or select projects to offer it only there.
Only an administrator can create, change, or remove a link type. A built-in type's direction is locked, and a type still in use on any link cannot be removed.
Open Settings → Labels. One label list serves every project and every page space on the server.
An item auto-creates a label the first time someone types a new name into its label field. The new label carries no color. This is why the list grows on its own.
To add a label by hand, type a name, select a color, and click Create
label. The name must be unique. You need the label.create permission
atom, held globally.
Click the pencil to rename a label or change its color. You need
label.update, held globally. Click the trash icon to remove a label. You
need label.delete, a separate atom, held globally. Removing a label
removes it from every item and page that carries it. This cannot be undone.
Open Settings → Cycles. Cycles are global: every project shares the same list, and a cycle can hold work from more than one project.
The server computes a cycle's status — draft, upcoming, active, or completed — from its dates. It never stores the status directly. A cycle with no start and end date is a draft: a staging area you can schedule later. Settings → Cycles is the only place a completed cycle stays visible. This page folds completed cycles under a Completed section, out of the way of the live ones.
Click New cycle to create one:
- Type a name.
- Set a start date and an end date, or leave both blank for a draft cycle.
- Add an optional goal.
- Select who the cycle is visible to — leave it on everyone, or select teams to restrict it to their members (and administrators).
- Turn on Recurring cycle to create future drafts of the same label automatically, on a weekday cadence and a fixed duration in days.
You need the cycle.update permission atom, held globally, to create,
change, delete, or complete a cycle.
Open Settings → Time logging. This page holds the instance-wide time policy: what people select when they log time, what a working day means, and the holidays that interrupt it. Turn on time logging for one project from that project's own settings.
Work categories is the shared list people select from when they log time — for example Development, Meeting, or Testing. Type a name and click Add to create one. Archiving a category removes it from the picker but keeps it on every worklog that already used it.
What a working day means holds four settings:
| Setting | What it does | Default |
|---|---|---|
| Working week | The comma-separated working days. Business-day SLAs resolve this per project; a project can override it in its own settings. | mon,tue,wed,thu,fri |
| Hours per working day | What a 1d duration means when logging time or setting an estimate. Instance-wide only — a project cannot override it. |
8 |
| Timesheet: minimum hours per workday | A working day with less logged than this is flagged as under-logged on the timesheet's per-person view. | 6 |
| Timesheet: maximum hours per day | A day with more logged than this is flagged as over-logged. | 10 |
A day someone spent on leave, or a team holiday, is never flagged by the two thresholds above.
Holidays are public holidays defined per team — a regional team can carry different holidays from another. A holiday marks every current member of its team away on the timesheet for its date range, and exempts those days from the under- and over-logged flags above. To add one, select a team, type a holiday name, set the from and to dates, and click Add holiday. Only an administrator can add or remove a team holiday. This section appears only when the leave plugin is turned on.
Open Settings → Automations to see every automation rule on the server —
the same rules list documented on Automations. You need the
automation.manage permission atom to open the page.
Open Settings → Canned responses. A canned response is a reusable reply
snippet: anyone can insert one from the comment composer, but changing the
list here needs the canned.update permission atom. Canned responses are
part of the reply flow documented on The service desk.
Open Settings → Forgejo. A Forgejo connection is one host: its base
URL, a webhook secret, and an optional read-only API token used for the
connection test and for backfill. A repository is one project on a
connection, added by its owner/repo name.
A connected host links its own pushes, branches, and pull requests to work
items by key. A commit message, branch name, or pull request title carrying
RADD-1234 links itself to that item. Click Backfill to walk a
repository's branches, pull requests, and commits through the API instead,
and link everything that predates the webhook. Backfill needs the
connection's API token.
A work item's key is unique across the whole server. This is why the link-by-key match works from any connected repository, whatever project it is mapped to. Mapping a repository to a project sets only a default — the project a published release lands in. It is never a filter on which items can link to it.
You need the global.manage permission atom to manage connections and
repositories.
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.