Projects and access

Projects and access

A project is the container everything else sits in: its tickets, sprints, epics and board all belong to one project. Projects are also where access is decided — people see a project through the groups that have been granted it.

Where: Projects in the main menu, or Settings › Project Manager to create and edit

Creating a project

A project needs:

  • Name — what people see
  • Slug — a short uppercase code, like KDV. This becomes the prefix of every ticket key in the project (KDV-123), so choose it once and choose it well
  • Lead — the person responsible, plus an optional backup lead
  • Description, and a project colour so it is recognisable at a glance
  • Open — whether the project is open or closed to new work

Access is granted through groups

You don't add individual people to a project. You add access groups — the teams defined under Users and groups — and everyone in those groups can see and work the project.

That has a practical consequence: when someone says "you don't have access to this issue" stopped them opening a ticket, the fix is to add them to a group the project trusts (or add their group to the project), not to fiddle with the ticket.

Custom statuses

Each project can define its own custom statuses — its own labels for the stages work moves through — and map each one to a system column (To Do, In Progress, Under Review, Done, On Hold, Blocked). Add them in the project's settings with a name and the column it belongs to.

This is how a development project gets QA Testing and Pending Deploy while another project keeps things simple — without the board or reports fragmenting, because everything still rolls up to the same six columns. The full explanation is in Statuses, priorities and ticket types.

Rules and things to watch

  • The slug is destiny. Ticket keys are built from it, and if you connect GitLab, branch names must start with the ticket key for linking to work — so a rename-happy slug would break more than aesthetics. Treat it as permanent.
  • Leads are accountability, not permission. Setting someone as lead makes them the owner of the project's health; access still flows through groups.

Related articles