Warning: stale info!

This comparison was done in 2016. The plugin landscape has evolved since then, and I have not had time to update this comparison.

Sometimes in JIRA you want a checklist, or todo list for your issue, just like Confluence's Task List. What are your options?

  1. You could model your todo items as sub-tasks. Advantages: todo items can have assignees, due dates, and a fancy workflow. Disadvantage: visual clutter, difficult to use, and you don't need the full power for JIRA for something this simple.
  2. You might try to use JIRA's built-in 'Checkboxes' field type for a 'Todo' field. This does not work. With JIRA checkboxes, only checked items show. Unchecked items are considered to be "irrelevant to this issue", and so don't display except when editing. A todo list with no completed items wouldn't show up at all. In a todo list, unchecked means "task is not yet completed", which makes it just as (or more) important than checked items.
  3. Consider the various JIRA checklist / todo list plugins.

Here we review a handful of checklist / todo list plugins available (in February 2016), seeing how they stack up to each other and the built-in Checkboxes field.

Built-in JIRA CheckboxesMy Todo (previously ToDo list custom field)

Kanoah Checklist

Checklist for JIRAIssue Actions TodoSimple Tasklists
Price (Oct '20)n/a10 / 85 / 150 / 310 / 650 / 900 / 2200 / 2700 /  350010 / 25 / 50 / 100 / 200 / 250 / 275 / 325 / 32510 / 90 / 175 / 330 / 675 / 990 / 1350 / 2300 / 275010 / 55 / 100 / 185 / 565 / 850 / 1060 / 1350 / 155010 / 50 / 100 / 180 / 300 / 400 / 700 / 1000 / 1000
Price (Feb '16)n/a$010 / 25 / 50 / 100 / 200 / 250 / 275 / 325 / 325

10 / 35 / 75  / 150 / 325 / 480 / 650 / 875 / 950

10 / 50 / 90 / 160 / 480 / 700 / 900 / 1000 / 120010 / 20 / 40 / 80 / 125 / 200 / 200 / 400 / 400
Issue View

JIRA only displays the values of checkboxes that have been ticked.


By default only the first two checkboxes are shown, which is bad since it hides even ticked items.

Fortunately this behaviour can be turned off, showing all checkboxes:

Strikethrough can also be turned off. Stars indicate 'required' fields. One can also set a 'Status' for an item ("Not Applicable", "In Progress", "Blocked"):

Not a custom field, but rather a tab:

Simple Tasklists is not a custom field, but rather some specially formatted text (macro) in the issue description:

All Checkboxes Ticked
Edit View

Note the ability to edit/delete items on the fly

In edit mode one can tick boxes, set statuses and add/edit new items,

An issue's tasks can be completed by ticking the checkbox, and can be edited by clicking the pencil icon, yielding the same Edit screen used for template editing:

Here are the {task}'s in the description, plus the rendered view on the right.

One can also have 'templates', centrally predefined sets of tasks:

Then by typing '{tasklist}Milestones{tasklist}' in an issue description or comment, the description expands to template's set of tasks (see previous screenshot).

Search Results / List View

(Linux users may experience wonky formatting)

Issue actions cannot appear in search results (no field 'list view').

The only way to view an issue's tasks in search results is by adding the macro to the issue Description, and then adding the 'Description' field to the search columns:

The checkboxes work even within search results (as of v1.0.8, see correspondence), which allows one to update tasks rapidly across multiple issues.

Structure View

(Note: they're all terrible; see Groovy Script - simplified views of fields)

Issue actions cannot appear in search results (no field 'list view').

The Structure view renders the first few lines of Description in its 'Summary column'. When those are {task} macros, they do render, but the results are not particularly useful:


Not searchable (confirmed with vendor), as of v1.3.1 / March 2016.

Not searchable.Search is not possible, but reportedly on the roadmap. See https://answers.atlassian.com/questions/37042662/ability-to-search-for-an-issue-by-tasklist-item-status

Options are defined centrally:

Options are defined per-issue. New issues acquire the Default Value.

Due to what seems like a bug, the Default Value doesn't display. One has to click 'Edit Default Value' to see them:

Options are defined per issue. New issues acquire the Default Value:

Options are defined centrally, but per-issue options may be added by end users, without breaking the link to those centrally defined options.

Todo items are defined per issue. New sets of Todos may be created based on global or project-wide templates.

A global template:

Options/Tasks are defined per issue. New issues may acquire a set of options from a referenced Template.



  • Strike through is optional
  • Items can be made 'mandatory', towards a 'Completed' field status.
  • Addition of new items can be restricted by role

A few tweaks are available:

Internal Database Representation

customfieldvalue.stringvalue stores ID references to predefined options:


customfield.textvalue stores one JSON field per issue, with direct option values:

[{"id":"Overview Doc Written","type":"done"},{"id":"High Level User Stories Written","type":"done"},{"id":"UX Design Developed","type":"done"},{"id":"Eng Tech Spec Written","type":"todo"},{"id":"Eng t-shirt Size & Quarter Commit","type":"todo"},{"id":"All Sprints Scheduled","type":"todo"}]

customfieldvalue.textvalue stores one JSON field per issue, with direct option values:

[{"description":"Overview Doc Written","checked":true},{"description":"High Level User Stories Written","checked":true},{"description":"UX Design Developed","checked":true},{"description":"Eng Tech Spec Written","checked":false},{"description":"Eng t-shirt Size & Quarter Commit","checked":false},{"description":"All Sprints Scheduled","checked":false},{"description":"All Code Checked In & Tested","checked":false}]

customfieldvalue.textvalue stores JSON records (one per checkbox), referring to a predefined option.


For per-issue checkboxes, "name" has a value and "optionId" is 0.

A custom table, "AO_9701C1_ISSUE_ACTION, stores todo items for issues and templates:

A group of todos is defined in the AO_9701C1_ISSUE_ACTION_GROUP table.

A custom table, AO_5345B8_TASK, is used to store tasks, which the {task} macros simply reference:

Likewise for tasklists:

  • Free, with all the implications for support that entails
  • Compares favorably with Kanoah.
  • No search.
  • The search/list view displays a progress bar rather than attempting to list the checkboxes, which might work well in some scenarios and not in others.
  • Support is via a custom JIRA Service Desk instance. While possibly good for privacy-conscious users, it means there is no answers.atlassian.com "knowledge base" to tap into.
  • The only viable choice if you need centrally managed task definitions, while still retaining the flexibility of per-issue tasks.
  • Has per-item statuses and special formatting of @user mentions and dates.
  • Has relevant workflow post-functions and validators.
  • Creating a task list is rather an involved process: click on the Todo tab, pick a template and give the new Todo list a name; then Edit the new Todo list and assign a user; at which point you finally get checkboxes.
  • Multiple distinct sets of todos per issue.
    • Notifications to watchers, permissions and other fancy features (see docs).
  • Support via custom website; no answers.atlassian.com "knowledge base".

Simple Tasklists is interesting, because tasks can be interspersed within a free-form issue description, or added via comments, and are all nicely aggregated by the Task panel. Like in Confluence, tasks can be assigned via @mention reference, and will appear in a user's task tray.

The plugin has some limitations and missed opportunities at present:

  • Like all alternatives except Checklists for JIRA, issues do not share task list definitions (in practice, this means a {tasklist} expands immediately to a series of {task}s). Each issue's set of tasks varies individually, and changing the templates will only affect new issues.
  • There appears to be no search-for-issues-by-task facility (link).
  • As there is no specific field to appear in search results. The Description field can do the job, but only if it contains all {task}s, and none were defined in comments.
  • The database refers to issue keys (e.g. PRJ-9), which probably will break if projects are renamed.


I would recommend Checklist for JIRA, being the only plugin allowing centrally managed Task list definitions (i.e. where you can edit a Task definition once, and see the change across all issues), while still allowing per-issue tasks. Checklist for JIRA also comes with a nice set of JQL filters, and the ability to mark tasks 'Mandatory' and other features. Finally, the fact that it uses the standard custom field API is preferable to plugins that become unique snowflakes by implementing their own database tables.

If you don't mind task lists differing per issue, the free ToDo list custom field plugin does a great job.

The Simple Tasklists and Issue Actions Todo plugins implement their own database back-ends, rather than using the custom field API. As a result, neither allows for searching of issues by todo status, or displaying todo status in gadgets. Neither takes the opportunity to make task definitions reusable. Simple Tasklists is interesting, in that it uses the flexibility of a custom back-end to allow for wiki-like interspersing of tasks with description text and comments.

I shall endeavour to keep this page updated – please drop me a line if anything is incorrect or outdated.

  • No labels

1 Comment

  1. The Gebsun checklist plugin is cloud-only, and thus not relevant to me, but good to note its existence.