Projects

Where tickets live, who can see them, and what a project contains.

Projects are the first of Alba Ticket's five modules, and the one every team uses: the other four, Helpdesk, Knowledge base, Time and the CRM, build on the projects, tickets and people here. A project groups tickets under a short key such as HELP or WEB. Ticket keys are the project key plus a number, so HELP-42 is the forty-second ticket in the helpdesk project. Keys never change and old links keep working.

Kinds of project

• Software projects track development work and usually use boards and sprints.
• Helpdesk projects serve customers and add request types, queues, internal notes and, when imported from Jira Service Desk, SLAs and approvals. See Helpdesk projects.
• Sales projects hold deals: one ticket type, Deal, on a pipeline from Qualified to Won or Lost, with a board over its stages. See Sales pipeline.
• Business projects are for everything else.

The kind changes which features are shown. The tickets themselves work the same way everywhere.

Finding a project

The projects page shows every project you can see as a card with its key, kind, lead, description and the number of open tickets. Type in the search box (or press f) to narrow the list by key or name, switch My projects on to keep only the projects you lead or are a member of, and choose whether to order by name or newest first. Twenty projects are shown at a time, with Previous and Next under the list. The filters and page are part of the page address, so a filtered list can be bookmarked or shared.

Moving around a project

Every page about one project, from its ticket list to a board for it, carries a menu down the left edge. It starts as a rail of icons: the project's key at the top, then Tickets, New ticket (the ticket dialog with this project chosen), Components, Versions, Queues on a helpdesk, the board you are on (or the project's first board) with its Backlog and Reports when it is a scrum board, All boards when the project has several, and Settings for installation administrators. Hover over an icon for its name, or press the chevron at the foot of the rail to expand the menu and show the labels; the browser remembers the choice. On a phone the rail gives way to a bar at the top of the page with the project's name and the page you are on: tap it for the same entries. Boards over several projects have no menu, since they are not about one project.

Membership and roles

You see a project when you are a member of it, directly or through a group, or when you are an installation administrator. Each membership carries a role, and roles grant permissions:

The default roles are Administrator, Member (who works on tickets and logs time to them), Reporter (who raises tickets, comments on them and edits the ones they reported) and Viewer, and four for time and billing: Consultant (logs own time), Team lead (sees the team's time), Account manager (runs the customer relationship, billing included) and Finance (sees the money, logs nothing). Administrators can add roles with any mix of permissions.

A role is held on a project or on a customer. An organisation that projects are billed to is a customer, and a role given on it under Organisations in Administration applies to every project billed to it, so a consultant assigned to a customer can log time on all of that customer's projects without being added to each one. The CRM's permissions in a role count only where the CRM puts them: on a customer, for that company alone, or in a workspace CRM role, for every company; on a project they give nothing (see Who may see and change the CRM).

Project settings

Settings at the foot of a project's left-edge menu opens its settings for anyone with something there to change. A member whose role has Administer project sees all of them: ticket types and workflows, members, components, versions, labels and security levels, and for a helpdesk its request types, queues and SLAs. A member whose role has Manage helpdesk forms sees a helpdesk's request types alone, and is offered Anyone, with no account for a form only with Publish helpdesk forms too. Editing the project's name and details, archiving and deleting it stay with installation administrators. Members with neither permission have no Settings entry.

The settings page follows other people's changes: what another administrator adds or changes appears without a reload, and anything you are typing in the page's add boxes stays. If you have a label, security level, queue or request type open for editing and someone else changes it, the dialog says so and shows their version; your save is refused until you load theirs, so neither of you overwrites the other unseen. A record deleted while you edit it closes the dialog with a note, and if your own permission is taken away while the page is open, you are sent back to the project.

What a project contains

Besides tickets, a project has:

• Ticket types it allows, each with a workflow. One type is the default for new tickets.
• Components, named parts of the product a ticket can belong to, each with an optional lead; see Components.
• Versions that tickets can affect or be fixed in, with release dates and a released state; see Versions.
• Labels, free-form words that belong to the project.
• Security levels that restrict who sees a ticket.
• Custom fields that apply to the project, set up by an administrator.

How each of these is managed is on Managing projects.

Components

Components name the parts of a product, such as Checkout or Catalogue, so tickets can be grouped by the area they touch. Open Components in a project's menu to see them: each one's lead, who new tickets in it go to, and how many live tickets it holds. The count links to the ticket list filtered to that component; the filter chip at the top of the list clears it.

A ticket can belong to any number of its project's components. Choose them in the New ticket dialog and on the edit form, and they appear under Details on the ticket page and in its history.

Default assignee

Each component can decide who a new ticket in it is assigned to when nobody is chosen: the component's lead, the project's lead, nobody, or the project's own default. When a ticket is created in several components, the first one with a setting of its own decides. Tickets imported from Jira keep the component's assignee type from there.

Managing components

Project administrators add, edit, archive and restore components on the same page. Archiving keeps the component on existing tickets and in their history but takes it out of the choices for new ones; restoring brings it back. A component's name is unique within its project.

Versions

Versions are the releases and milestones a project ships. A ticket can be fixed in any number of them, which is what goes into release notes, and can affect any number of them, which is where a bug was found. The same version can be both.

Open Versions in a project's menu to see them: each one's dates, whether it has been released, how many tickets are fixed in it and how many it affects. A warning badge next to the fix count says how many of those tickets are not resolved yet, so you can see quickly what a release is still waiting for. Both counts link to the ticket list filtered to that version, and the chip at the top of the list clears the filter.

Choose versions in the New ticket dialog and on the edit form; they appear under Details on the ticket page and every change is recorded in the ticket's history.

Managing versions

Project administrators add, edit, release, archive and restore versions on the same page. Releasing stamps the release date if it is empty; a released version can be marked unreleased again if it goes out late. Archiving takes a version out of the choices for new tickets while keeping it on the tickets that already carry it; restoring brings it back. A version's name is unique within its project. Versions imported from Jira keep their dates and released state.