Skip to content

Work items

Hussein Jarrar edited this page Sep 12, 2026 · 2 revisions

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.

The three levels

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.

The key-addressed URL

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.

Creating an item

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.

The New item dialog for the RADD project, showing the title field, the rich-text description editor, and the two-column field grid

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 item page

The full page for epic RADD-1000: header actions, title, description with What is wanted / What changes / Where / Done when sections, and the properties rail on the right showing AI, Fields, State, Type, Priority, Participants, Assignee, Reporter, Team, and Cycle

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 rail, on its own

The properties rail for issue RADD-997: State (Done), Type (Bug), Priority (Blocker), a Participants panel, Assignee (Unassigned), Reporter (Hussein Jarrar), Team (None), and Cycle (No cycle)

Editing the description

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.

Comments

The Comments tab: the tab bar (Comments, History, Work log, Version control), an empty thread, the Public reply / Internal note toggle, and the comment composer

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.

The same composer with Internal note selected, showing the amber highlight the internal composer carries

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 (plus project.manage holders) 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.

State and the workflow

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.

Children: epic progress and subtasks

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:

The Subtasks panel on issue RADD-903, expanded to show four completed subtasks with strikethrough titles and avatars

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

Links between items

The Dependencies panel on RADD-903, expanded: one "Relates to" link to RADD-872, and the add-link form (a Link type dropdown and an item search)

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.

Flag, star, and watch

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.

Fields you cannot edit

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.

Bulk actions

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 and delete

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.

Clone this wiki locally