Vocabularies, fields and workflows

The ticket types, statuses, priorities and resolutions shared by every project, custom fields, and the workflows tickets move through.

Three things are shared by every project and managed only here: the vocabularies tickets are described with, the custom fields that add to them, and the workflows they move through.

Vocabularies

Ticket types, statuses with their categories (to do, in progress, done), priorities, resolutions and link types are shared by all projects. Add and rename them here, and set their position to change the order they are offered in.

A ticket type also has a level: standard, sub-task or epic. The level decides where the type may be used rather than how it looks: Add sub-task on a ticket offers the sub-task types, an epic offers the standard ones, and a ticket with children of either kind becomes a lane on a board.

Custom fields

Fields of your own on tickets, in addition to the built-in ones. Custom fields lists every field with its key, its type, whether a value is required, how many projects and ticket types it applies to, and how many tickets hold a value. Archived fields stay on the list, marked, so it is clear why their values are still on tickets.

A new field takes a name, a key suggested from the name, a type, an optional description shown under the field on the ticket form, and a default where the type takes one. Tick the projects and ticket types it applies to; leaving both untouched means every project and every ticket type. Select, radio and checkbox fields get a list of choices you can add, rename, reorder, disable and remove. Disabling a choice keeps it on the tickets that already have it but stops anyone choosing it again, and a choice tickets are using cannot be removed.

Once tickets hold values, the key and the type are fixed: changing either would strand the values. Archiving takes a field off ticket forms and keeps what is already stored, and restoring puts it back. A field can only be deleted outright while no ticket has a value for it.

Fields imported from Jira appear here like any other. Types Alba does not model arrive as JSON fields holding the original payload, so nothing is lost; leave them alone unless you are sure.

Workflows

A workflow is a set of statuses and the transitions between them. The Default workflow seeded on a new installation has one transition into each status, each allowed from any status, so boards for it let a card move to any column; a transition's conditions can still narrow who may run it. Workflows imported from Jira arrive as data and keep their own transitions.

New workflow asks for a name, a description, the statuses it uses and the status tickets start on. The statuses themselves come from the vocabulary, so add them there first.

Opening a workflow gives you its editor. On the left are its name, description, starting status and the statuses in it, with a picker adding any installation status that is not in it yet. A status cannot be removed while tickets sit on it, while a transition points at it, or while it is where tickets start; the page says which of the three it is.

On the right are the transitions, in the order people see them on a ticket. Each takes a name, a description, a From status, a To status, and a tick for whether it asks for a resolution or an assignee before it completes. Leaving From blank means the transition runs from any status, which is how the Default workflow is built. Transitions can be renamed, moved up and down, and removed; history keeps the moves a removed transition already made.

Under each transition are its rules, in plain words, grouped as conditions (who may run it), validators (what must be true first) and post functions (what happens afterwards). Add one from the menu and it asks for whatever that rule needs, such as which permission or which field. A rule imported from Jira that Alba cannot evaluate keeps its warning badge and its original class and arguments: it is never rewritten, only removed if you decide it no longer applies.