-
-
Notifications
You must be signed in to change notification settings - Fork 0
Work items
A work item is anything you track in Radd: an epic, an issue, or a subtask. This page covers the three levels, the item page, editing, comments, states, links, and the rules that decide what you can change.
Radd has three levels of work item, and the words are exact:
| Level | Is | Rule |
|---|---|---|
| Epic | A body of work made of several issues | Has no parent. Cannot contain another epic. |
| Issue | One thing someone works on | Belongs to at most one epic. What a commit names. |
| Subtask | A step inside an issue | Belongs to exactly one issue. A checklist line. |
An epic contains issues; an issue contains subtasks. The chain stops there — a subtask cannot have its own subtasks. "Work item" is the general term for all three.
Every work item opens at /issues/<KEY>, for example /issues/RADD-997.
The key is permanent: it does not change if you edit the title, move the
item between states, or reassign it. Type a key into the search bar to jump
straight to that item.
If an item moves to a different project, its old key keeps working and redirects to the new one.
Click New item. This button is always visible, and it creates the item
in whichever project you are currently viewing. You need the item.create
permission atom in that project.

Title is the only field you must fill in. Every other field defaults itself if you leave it alone: Kind defaults to Issue, State and Type default to the project's defaults, Priority defaults to Normal.
| Field | What it sets |
|---|---|
| Title | A short, imperative summary. Required. |
| Description | The item's body, in the rich editor. |
| Kind | Epic, Issue, or Subtask. |
| Type | The issue type (Bug, Task, Story, Feature, Epic, or a project's own types). |
| State | The workflow state the item starts in. |
| Priority | Low, Normal, High, or Blocker. |
| Parent epic / Parent issue | Required for a subtask, optional for an issue, forbidden for an epic. Search spans every project. |
| Assignee | Who does the work. |
| Team | The team the item is routed to. |
| Cycle | The cycle to plan it into. |
| Release | The version it targets, from this project's own releases. |
| Start date / Target date | Planning dates. |
| Points | Story points, only shown when the project has points turned on. |
| Labels | Free-text tags, shared across the whole server. |
| Custom fields | Whatever fields this project defines. |
A field you cannot write is disabled here the same way it is on the item page — see Fields you cannot edit, below.

The page has a reading column on the left and a properties rail on the right.
Header. The kind icon, the key, a child count on an epic, and a link to
the parent epic if the item has one. On the right: Watch, Star,
Archive, Delete (only if you hold project.manage), and Flag.
Title. Click it to edit. It saves when you click away or press Enter.
Description. The item's body, in the rich editor — see Editing the description, below.
The rail. Every metadata field, grouped under the heading Fields. State, Type, and Priority always show first, each as a colored chip beside a dropdown. Below them, the rail shows whichever fields the project's Screens settings place on this issue type, commonly including:
- Assignee, Reporter, Team
- Cycle, Release, start and target dates
- Labels, Points
- SLA timers, Time tracking
Less-used fields collapse behind a More fields toggle. A plugin can add its own panel here too — a Participants panel (people who follow this item beyond its assignee and watchers) is one example.
Below the description, in reading order:
- Attachments — drag a file in, or click Upload.
- Epic progress or Subtasks — see Children: epic progress and subtasks, below.
- Dependencies, Mentions, and Related links.
- Comments / History / Work log / Version control — four tabs, covered under Comments, below.
Time logging and the timesheet covers Work log and the estimate. Attachments covers file storage and access. An AI panel offers Summarize and Find similar when AI features are turned on for the server.

The description is a rich editor: headings, bold and italic, strikethrough, code, links, lists, quotes, tables, and images. Click Edit on a description you can write, or click the empty placeholder to start one.
Type # followed by a search term to link another item. Pick one from the
list and the editor inserts a chip that opens that item on click. This also
records the link as a Mentions entry on both items — see Links between
items, below.
Type @ to mention a person. Type / to open a menu of quick actions —
change state, assignee, priority, or labels without leaving the editor.

A comment is Public or Internal. Public is the default and the only
option unless you hold comment.read_internal — then a toggle appears
above the composer.

An internal comment is never visible to a requester. Among staff, it is visible to:
- the comment's author, always;
- anyone holding
project.manage, always; - anyone holding
comment.read_internal, unless the author narrowed it to specific teams — then only members of those teams (plusproject.manageholders) can read it.
You need comment.write to post. If you do not hold it, Radd replaces the
composer with a note instead of an editor you cannot submit. This is the
same rule as Fields you cannot edit, below.
Click the State chip's dropdown to move an item. Radd grays out a state you cannot move to yet, and shows the reason on hover. The reason is often a required field that is still empty, or a value that must match first.
A project can guard a transition with a rule the move must satisfy — a field set to a particular value, or an approval granted. If you force a move that fails a guard, Radd refuses it and lists every unsatisfied rule as the error. A project can also turn guards off, or require that every move use an explicitly defined transition.
An epic's header carries a count chip ("5 children" in the screenshot above). Further down the page, under the heading Epic progress, a bar shows the same "done / total" count — click it to expand the bar into the list of issues.
An issue shows its subtasks the same way, under the heading Subtasks: a checklist, with a checkbox per line and a one-line "add a subtask" input:

Both sections sort open work first. What is left to do shows before what is already done, so you never scroll past it.

A link is a directional edge between two items, typed by a link type. The built-in types:
| Type | Outward | Inward | Symmetric? |
|---|---|---|---|
| Blocks | blocks | is blocked by | No |
| Relates | relates to | relates to | Yes |
| Duplicates | duplicates | is duplicated by | No |
| Mentions | mentions | mentioned by | No — and auto-managed, see below |
An administrator can add more link types on Settings → Link types, each global or scoped to chosen projects — see Projects.
To add a link, pick a type and search for the target item by title, number, or key; the search spans every project. Click the × on a link row to remove it.
Mentions is the one type you never add or remove directly. Writing a
# reference in a description or a comment — the chip the editor inserts —
creates a Mentions link automatically. It disappears if you remove the
reference from the text.
These three look similar but do different things:
| Action | What it does | Who sees it |
|---|---|---|
| Flag | Marks the item for attention. One shared flag on the item. | Everyone who can read the item. |
| Star | Marks the item as a personal favorite, for your own lists. | Only you — not shown to anyone else. |
| Watch | Adds you to the item's notification list. You get notified of state changes and comments. | The watcher list itself is visible to anyone viewing the item — hover Watching to see who. |
You watch an item automatically when you are assigned to it, comment on it, or create it. Watch is the manual override, for following an item you are not otherwise tied to.
Radd disables a field you cannot write. It does not let you edit it and then fail on save. A disabled field is dimmed, and the reason appears when you hover over it — there is no lock icon.
Radd enforces this one rule everywhere a field appears:
- on the item page's rail and title;
- on the New item modal, for a project that restricts a field on create;
- on the comment composer, when you cannot comment at all;
- on the bulk action bar, per field, for a single-project selection.
The server decides this per person and per project. Two common reasons: you
lack item.update on this item, or a grant restricts only that field to a
smaller group.
Select more than one item in a view (its checkboxes) to open the bulk action bar at the bottom of the screen. It can set State, Priority, Assignee, Team, Type, Cycle, and Release, add or remove one Label, flag the selection, or archive it. Move… re-keys the whole selection into another project (states and types map by name; releases and fields the target project does not define are dropped).
A bulk action never fails as a whole. Radd checks each item on its own, and skips any it cannot update. The reason is one of: not found, no permission, not applicable, or blocked by a transition rule. The result reports how many succeeded and how many were skipped.
Bulk actions cannot delete items. Deleting is a single-item action, from the item page.
Archive hides an item from boards, lists, and views by default. It
stays reachable by its key, and the archive action leaves its data
untouched. You need item.update to archive an item, and you can
unarchive it at any time.
Delete removes the item permanently. It needs item.delete, which
project.manage also grants. An item with children refuses to delete —
delete or re-parent them first. Deleting removes the item's row and its
comments. The event history that recorded its past changes stays, so the
audit trail survives after the item is gone. This cannot be undone.
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.
-
Developer guide
- Architecture: the kernel and plugins
- Develop, test and deploy
- Events and consumers
- Permissions and access control
- The MCP server
- The query language for developers
- The REST API and authentication
- Write a backend plugin
- Write a page editor extension
- Write a plugin user interface
- Write an automation node
-
Release notes
- 0.36.4
- 0.36.3
- 0.36.2
- 0.36.1
- 0.36.0
- 0.35.0
- 0.34.0
- 0.33.0
- 0.32.0
- 0.31.1
- 0.31.0
- 0.30.0
- 0.29.0
- 0.28.0
- 0.27.0
- 0.26.0
- 0.25.1
- 0.25.0
- 0.24.1
- 0.24.0
- 0.23.1
- 0.23.0
- 0.22.0
- 0.21.0
- 0.20.0
- 0.19.0
- 0.18.1
- 0.18.0
- 0.17.2
- 0.17.1
- 0.17.0
- 0.16.0
- 0.15.0
- 0.14.1
- 0.14.0
- 0.13.1
- 0.13.0
- 0.12.0
- 0.11.0
- 0.10.0
- 0.9.2
- 0.9.1
- 0.9.0
- 0.8.1
- 0.8.0
- 0.7.1
- 0.7.0
- 0.6.6
- 0.6.5
- 0.6.4
- 0.6.3
- 0.6.2
- 0.6.1
- 0.6.0
- 0.5.0
- 0.4.1
- 0.4.0
- 0.3.2
- 0.3.0
- 0.2.0
- 0.1.0
-
User guide
- AI features
- Attachments
- Automations
- Cycles and releases
- Instance settings
- Intake forms and the portal
- Notifications and the inbox
- Personal settings
- Project settings
- Projects
- Reports and dashboards
- Search and the query language
- Start here
- The application window
- The card designer
- The roadmap
- The service desk
- The wiki
- Time logging and the timesheet
- Views
- Work items