Overview

The ToDoList plugin lets users create ordered lists of tickets and interact with them with a streamlined user interface.

Overview

A ticket can belong to zero, one, or many lists simultaneously. Aside from their position in a list, tickets have no additional properties within a task list's context besides their core properties. So, for example, if a ticket is closed in one task list it will be closed in all task lists.

Task lists have very few core properties: a slug and title, optional description, creation timestamp and creator, and some configuration.

When viewing a task list, the user can:

• Click on a ticket summary to show the ticket's properties, [(@@TODO) comments and change history] in a modal dialog
• Create a new ticket within the task list at any position in the list
• [(@@TODO) Expand a ticket's own tasklist as a "sub-list"]
• [(@@TODO) Create a new tasklist associated with a ticket in the list]
• Act on a ticket, with or without leaving a comment

Ticket Hierarchies

[(@@TODO) A task list may be attached to a particular ticket, in a one-to-one relationship. This allows users to attach additional ticket-like properties (owner, priority, deadline, milestone, etc) to a task list. Users can then browse, sort, filter, and search for task lists according to their inherited ticket properties, using a familiar TicketQuery interface.]

Tickets in a task list are ordered but non-hierarchical: all tickets in a task list exist at the same level. [(@@TODO) To create a nested hierarchy of tickets, users can create a new task list attached to a ticket that is already within another task list, and can then add tickets to that new task list. When the "parent" task list is being viewed, the user interface will then display an interactive drop-down button next to any tickets that have their own task lists attached to them. Clicking on this button will expand the tasklist attached to that ticket. This allows users to create arbitrarily nested task hierarchies. No constraints are imposed; the same ticket may be both a parent tasklist and a child task, and infinite loops are therefore possible.]

Task List Configuration

Task lists are heavily workflow-driven: tickets within a task list are considered "active" or "completed" based on their status, and all ticket manipulation is done through ticket workflow actions. Within a task list, "completed" tickets are hidden by default, [(@@TODO) but can be shown inline with active tickets, or alone without any active tickets displayed, by toggling a state button in the task list display].

Certain behaviors of a task list are configurable and are controlled by properties set on the task list itself:

• The set of ticket statuses that are considered "completed" for this list (default: ["closed"])
• Zero or more workflow actions that should be presented as action buttons (default: ["leave", "resolve"])
• [(@@TODO) For each action button, whether leaving a comment is mandatory or optional (default: {"leave": "mandatory", "resolve": "optional"})]
• [(@@TODO) The HTML representation of each action button]
• [(@@TODO) A set of visual styles to apply to each ticket in the list based on the ticket status (default: {"closed": {"text-decoration": "line-through"}})]
• [(@@TODO) The set of ticket fields that should be displayed in the task list]