Project settings
Project settings hold the configuration for one project: its workflow,
access, types, releases, and more. Open them at Settings on the
project, or at /p/<project key>/settings. There are nine sections.
Some settings cascade: an instance default applies to every project, and a project can override it. Settings → General (the instance-wide page) sets the default. A project settings page that edits one of these values shows a badge next to it:
- Set here — this project overrides the instance default.
- Inherited — this project uses the instance default. Change it, then click Save, to override it for this project alone.
A Reset button appears next to an overridden value. It removes the project's override and returns to the instance default.
The General section holds cascaded settings that have no section of their own. Today that is one setting:
| Setting | What it does | Default |
|---|---|---|
| Story points | Lets people estimate items in story points (0–999) alongside time tracking. | Off |
You need the project.manage permission atom in the project to change this
page.
Radd sets a project's name and key when you create the project. The interface has no page to rename a project or change its key afterward.
Access lists who can act in this project. Each row grants one role to one person, one team, or one directory group. A grant to a team or group reaches every member of it, including nested members.
To grant access:
- Search for a person, team, or directory group.
- Select a role.
- Click Grant access.
To remove access, click the X on its row. This does not remove access that came from an instance-wide role. Radd manages those on Settings → Roles, not per project, and does not list them here.
You need the member.create permission atom to grant access, and
member.delete to remove it. The project.manage permission atom
includes both.
The Workflow section has two parts: the project's states, and its transitions.
A state is one step an item moves through, such as Backlog or In Progress. Every state belongs to a fixed category (Triage, Backlog, Todo, In Progress, Done, or Canceled) that drives reporting and board columns. You name the state; the category is fixed.
To add a state, type a name, select a category, and click Add state. To reorder states, use the up and down arrows on a row. To delete a state, click its trash icon, then select which state its items move to.
The Categories list below the states is instance-wide: every project shares the same category names and colors, though the underlying six behaviors are fixed. Only an administrator can add, rename, or remove a category.
You need the state.manage permission atom to manage states in a project.
A transition is an optional guard on one state change. Each transition names a from state (or Any state) and a to state. It can carry conditions an item must meet, and approvals it must collect, before Radd allows the move. Radd checks rows top to bottom: the first transition whose Applies when matches the item governs the move.
The Enforcement setting controls what happens when no transition matches:
| Mode | What it does |
|---|---|
| Off | Anyone can move an item to any state. Radd ignores the transitions list. |
| Guarded | A move that has a transition defined must meet its conditions and approvals. A move with no transition defined stays allowed. |
| Strict | The transitions list becomes the complete map. Radd refuses a move with no transition defined. A defined move still checks its conditions. |
This is precise: in Guarded mode, an undefined move stays free, and only a matching transition's conditions can stop a move. In Strict mode, Radd always refuses an undefined move.
The instance-wide default is Off. A project can override it here.
To add a transition, select a From state (or Any state) and a To state, then click Add transition. Add conditions with + Add a condition…. Scope the transition to specific items with + Scope by a field… under Applies when.
An issue type classifies what an item is, such as Bug, Task, or Story. A type is a separate axis from the epic, issue, and subtask hierarchy — a Bug and a Story can both be issues. Each type has its own color, shown as a chip on boards, lists, and the issue view.
To add a type, type a name, select a color, and click Add type. Click Make default to make a type the one new items get. Click Template to set text that pre-fills the description of a new item of that type.
You need the project.manage permission atom to manage issue types.
A screen arranges which fields show on the issue view, per issue type. Each field is Shown, Collapsed (behind the peek panel's "More fields" toggle), or Hidden. A screen controls what shows, not what a field can hold: it never deletes a field's value or changes its validation.
An issue type with no screen of its own falls back to the project default. Core fields (state, type, priority) always show and are not listed.
Select an issue type at the top to edit its own screen. Leave Project default selected to edit the fallback every type without its own screen uses. Reorder fields with the up and down arrows, set each field's placement, then click Save layout. Click Reset to default to clear the screen for the selected scope.
You need the project.manage permission atom to change a project's
screens.
A release is a target work items point at, with its own version string
(such as 1.2.0) and name. Its status is planned until you mark it
released.
To create a release, click New release, enter a version and a name, and click Create release. To mark a planned release as shipped, click Mark released on its row.
Two settings, further down this page, name the states a sweep uses:
| Setting | What it does | Default |
|---|---|---|
| Waiting-for-release state | The state a merged change moves work to: finished, not yet shipped. In the Done category, so throughput counts the day the work finished. | Empty (off) |
| Shipped state | The state a sweep moves waiting items to. | Empty (off) |
A sweep moves every item sitting in the waiting-for-release state into the shipped state, and records the release on each one. This page has no button that runs a sweep. Radd runs one automatically when a connected Forgejo repository publishes a matching release (Settings → Forgejo). An administrator can also run one directly through the API or an MCP tool. Leave either setting above empty to turn the pipeline off.
You need the release.update permission atom to manage releases in a
project.
An intake form creates a work item from a title and a set of registry fields you select. Read Intake forms and the portal for how to build a form and where people submit it from.
You need the form.manage permission atom to manage a project's forms.
Without it, this page shows nothing to edit.
Time logging is off for a project until you turn it on here. When on, people can log worklogs and estimates on the project's issues.
Below the on/off toggle, Working days names which days count as worked
in this project. The timesheet flags days logged under or over that
target. Business-day SLA targets also resolve this setting per item
project. The instance sets the default (mon,tue,wed,thu,fri); a project
can override it.
You need the project.manage permission atom to change either setting.
An SLA policy sets response and resolution targets for a project's service desk. Policies resolve first-match. For each item, the first enabled policy — top to bottom — whose priority filter matches is the one policy that governs it. Put specific tiers above catch-alls. Read The service desk for how SLA timers, breaches, and business hours fit the rest of the service desk.
To create a policy, fill in the form and click Create policy. Reorder policies with the up and down arrows on a row — order decides which policy wins a tie. Click Enabled or Disabled on a row to turn a policy on or off. Click the trash icon on a row to remove that policy.
Below the policy list, an After resolution section holds the CSAT (satisfaction survey) setting for the project — off by default. Read The service desk for what the survey does.
You need the sla.update permission atom to manage SLA policies. This is
an instance-wide permission atom, not a per-project one — unlike every
other section on this page, it does not delegate to project.manage.
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.