Tickets

Creating, editing, moving and resolving tickets, and what a ticket's page shows.

A ticket is one unit of work: a bug, a task, a customer request, a story. It has a type, a status in its workflow, a priority, a reporter and, once someone takes it on, an assignee. This page is about the ticket itself; comments, watching, sub-tasks, links and logged time are on Working together on a ticket.

The ticket list

The project page lists tickets. Use the tabs to switch between open, to do, in progress, done and all tickets, the Assigned to me button to see your own, and the search box to match keys, summaries and descriptions. The list is sorted by most recent update and shows fifty tickets at a time, with Previous and Next under it.

Creating a ticket

Press New ticket in the header; it is there on every page. A dialog opens over what you were doing and asks which project first. New ticket in a project's left-edge menu opens the same dialog with that project already chosen, and you can still switch. Then:

  1. Pick a type. In a helpdesk project you may pick a request type instead; it decides the type for you.
  2. Write a summary and, optionally, a description in Markdown.
  3. Fill in what else applies. The rest of the form is the same one Edit shows, in the same order: environment, priority, assignee, due date, components, versions, labels, the original estimate and any custom fields that apply to the type.

If you may edit tickets in the project you can also pick a Reporter, to raise the ticket for a colleague or a customer; left at "Me", it is yours.

Create saves the ticket and closes the dialog, leaving you where you were with the new key shown next to the button. Create and add another saves it and keeps the dialog open with the same project and type, ready for the next one. The ticket gets the next number in the project and starts in the workflow's first status. You automatically watch tickets you create.

Tickets can be placed in one or more of the project's components from the dialog; a component can decide who the ticket is assigned to when you leave the assignee empty. The dialog also offers the project's versions: the ones a ticket is fixed in, and the ones it affects.

Editing

Edit opens the same fields for an existing ticket, plus two that only an existing ticket has. Type changes what kind of ticket it is, to another of the project's types at the same level (a sub-task stays a sub-task) whose workflow has the status the ticket is in. Parent takes the key of the ticket it belongs under, such as an epic, or is left empty for none. Opened from a board's detail panel, the form goes back to the board when you save or cancel.

If someone else changes the ticket while you have the form open, the form says who. What you have not touched shows their version straight away; what you have changed is kept, and a line names the field and what they changed it to. Save changes saves only what you changed, so nothing of theirs is overwritten. If the ticket is deleted or moved to another project while you edit, the form says so and does not save.

Most changes do not need the form at all. On the ticket page, each line of Details has a pencil: priority, due date, components, fix versions, affects versions and labels are changed where they are shown, and each change is its own entry in the history. Press l to change the labels. The assignee has its own Assign dialog in the sidebar, which can also leave a comment.

Who can be assigned is the same everywhere a ticket can be given to someone (the New ticket dialog, the edit form, the Assign dialog and a workflow step that asks): the people who handle tickets in the project, which means members whose role lets them move tickets through the workflow, and installation administrators. Customers and people who only raise or read tickets are not offered. Setting the assignee on the New ticket dialog, the edit form or the Assign dialog needs the Change the assignee permission; without it the field is not shown. A workflow step whose screen asks for an assignee needs only the permission to move the ticket, since asking is the workflow's own choice; on a step that does not ask, only someone with Change the assignee can name an assignee with the move. A step's post functions may also change the assignee, whoever runs it: to the person moving the ticket, to its reporter or to nobody. A ticket keeps an assignee who has since left the project until someone changes it.

Preview under the description shows it as it will read. If you have typed something and try to leave without saving, you are asked first.

Fields that take several values, such as components, fix versions and affects versions, show what is picked as chips in a box. Click the box, or press Space on it, to open the list and tick or untick as many as you like; nothing already picked is lost by ticking another. A long list has a filter at the top: type part of a name to narrow it. Click elsewhere or press Escape to close the list.

Labels work the same way, and also let you add a new one: type it in the filter and press Enter. A label is one lowercase word, so spaces become hyphens. Labels are shown as coloured pills, and the colour comes from the name, so the same label looks the same on every ticket, list and board.

Descriptions and comments are written in Markdown, and the question mark beside such a field opens that guide. A ticket imported from Jira keeps its wiki markup until somebody edits it, when it is converted to Markdown for them to check before saving.

Details

Beside the status, the ticket page says how long it has been there: for 3d, for 5h, for 20m, or for just now in the first minute. The clock restarts whenever the ticket moves through the workflow, and tickets imported from Jira start from the last status change in their Jira history.

The details panel lists the same fields as the forms, under the same names and in the same order: priority, due date, components, fix versions, affects versions and labels, then the resolution, time tracking, last update and resolution time. A field with nothing in it says None, so you can see that it is empty rather than wonder whether it exists; components and versions are listed only where the project has some. A due date that has passed on an unresolved ticket is marked overdue. Change any of them with the pencil beside it, as described under Editing.

Environment is where the problem happens: the browser, operating system or release a bug was found on. It sits under the description on the ticket page and is written the same way, and can be filled in when a ticket is raised or later with Edit. Environments imported from Jira keep their original wiki markup and are shown as they were.

Time tracking compares the estimate with the work logged. Enter an Original estimate and a Remaining estimate on the edit form as durations such as 3h 30m, 2d or 45m, or an original estimate in the New ticket dialog; a day is eight hours and a week five days. The panel then shows what was estimated, what has been logged and what is left, with a bar and a warning once the logged time passes the estimate. Estimates imported from Jira come across with their tickets.

Moving through the workflow

A ticket's status is one of the statuses of its workflow, and a transition moves it from one to another.

A ticket moves through the statuses of its workflow by transitions Open to do In progress in progress Resolved done Closed done Start progress Resolve Close Reopen (clears the resolution) A transition has rules: who may run it (conditions), what must be true first (validators), what happens after (post functions). It can ask for a resolution, an assignee or a comment before it completes.

The Workflow panel lists the transitions you may run from the current status. Some ask for more before they complete, such as a resolution or an assignee, and every transition can carry a comment. A transition can be limited by conditions (for example, only the assignee may run it), checked by validators, and followed by post functions such as clearing the resolution. The workflow is chosen per project and ticket type by an administrator; see Workflows.

Resolved tickets keep their resolution and resolution time. Reopening clears them.

Security levels

A ticket can carry a security level that limits who sees it: named people, members of a group, holders of a project role, the reporter or the assignee. Tickets outside your level are left out of lists, boards, queues, searches and links, and their pages are not shown. Project administrators see every ticket in their project.

If you hold the Set security level permission, the ticket page's Security section, the edit form and the New ticket dialog offer the project's levels; "Visible to all members" clears it. The change is recorded in the ticket's history. Levels themselves are managed in the project's settings (see Administration) and come across from Jira issue security schemes.

Deleting a ticket

People with the delete permission see Delete on the ticket page. A deleted ticket disappears from every list and its page, but its key stays reserved and its history, comments and attachments are kept, so nothing else that referred to it breaks.

History

The history panel records every change: who did what and when, and for field changes, the old and new values. Comments, transitions, attachments, links and logged activities all appear there, as do commits and pull requests linked from a code host. The newest entry is at the top. The panel shows the newest fifty; press Show older under them to load earlier ones below.

Custom fields

Administrators can add fields of many kinds: text, rich text, numbers, dates, checkboxes, selects, users, groups, versions, components, ticket references and labels. Fields apply to chosen projects and ticket types and can be required. They appear on the ticket form and page under Fields. Administrators manage them under Custom fields. Data imported from Jira for field types Alba does not model is kept unchanged in a JSON field, so nothing is lost.