Projects
A project groups work items under one short key. This page covers what a project is, how to create one, and who can access it. It also covers what a project owns versus what it shares with the rest of the server.
A project has a key (for example RADD) and a name. The key
addresses every work item inside it: issue RADD-997 is the 997th item
created in the RADD project. See Work items for the full address format.
A project key is unique across the whole server, not only within a group of projects. Two projects can never share a key, so an item's key alone is enough to open it from anywhere.
Open Projects in the sidebar to see every project you can read. Each row shows:
| Column | What it shows |
|---|---|
| Key | The project's short address, for example RADD
|
| Name | The project's full name |
| Created | The date the project was created |
Click a row to open that project.
A project has no separate home dashboard. Opening a project takes you to its first view — usually a board — in the order the project's views are listed. Views covers how to read a board, a list, and a planning view.
The band above the columns names the project (RADD) and the view
(Board), and shows the total item count. Order and Display
control how the board groups and draws its cards. The application window names every part of this screen.
Click New project on the projects index. You need the project.create
permission atom.
Supply two fields:
| Field | What it does |
|---|---|
| Key | 1–10 letters and digits, starting with a letter. Becomes every item's prefix. |
| Name | The project's full name. |
A project starts with a default set of issue types (Task, Bug, Story, Feature, Epic), a default workflow, and three views (Board, List, Planning). You cannot change a project's key after creation.
TODO(verify): whether an instance-wide setting can require project keys to follow a naming convention beyond the 1–10 letters/digits pattern.
A project has no separate "members" list and "teams" list. Access is one list of role grants, each giving one role to a person, a team, or a directory group, scoped to this project. A grant to a team or a group reaches everyone in it, including nested groups.
Open Project settings → Access to grant or revoke access. Granting
needs member.create; revoking needs member.delete. A person who holds a
role instance-wide already has access and is not listed here — revoke
instance-wide access on Settings → Roles instead.
Project settings has nine sections: General, Workflow, Issue types,
Screens, Access, Releases, Forms, Time logging, and SLAs. Each section is
visible only if you hold the permission atom it needs in this project — for
example, Workflow needs state.manage and Releases needs
release.update. A project administrator normally sees every section; a
team lead granted a narrower role may see only some. Project settings
covers every section field by field.
This distinction confuses people, so this page states it plainly.
A project owns these. They exist only inside it, and two projects never share a row:
| Owned by the project | Set on |
|---|---|
| Workflow states and transitions | Project settings → Workflow |
| Issue types | Project settings → Issue types |
| Screens (which fields appear on which issue type) | Project settings → Screens |
| Releases | Project settings → Releases |
| Intake forms | Project settings → Forms |
| SLA policies | Project settings → SLAs |
A project shares these with the whole server. Changing one changes it everywhere it is used, not only in this project:
| Shared across the server | Set on |
|---|---|
| Labels | Settings → Labels |
| Cycles | Settings → Cycles |
| Link types | Settings → Link types |
| Work categories (for time logging) | Settings → Time logging |
| Custom field definitions | Settings → Fields |
A custom field is global by default. An administrator can narrow one to a chosen set of projects on Settings → Fields; with no projects chosen, it applies everywhere. A release, by contrast, always belongs to exactly one project — you cannot set an item's release to a version from another project.
Radd has no action to archive or delete a project once you create it. To remove a project from active use, archive or delete the work items inside it instead — see Work items for what each of those does.
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.