No results for ""

Projects

A project is the container for all your issues. Projects belong to an organization and each project gets a unique slug used in issue reference codes.

Project Slugs

When a project is created, a slug is derived from the project name. The slug:

  • Is URL-safe (lowercase, hyphens instead of spaces)
  • Is unique within the organization
  • Is used as the prefix for issue reference codes
  • Appears in the project URL

For example, a project named "Backend API" gets the slug backend-api and issues would be numbered BACKENDAPI-1, BACKENDAPI-2, etc.

Access Control

Project access can be restricted beyond the organization level. By default, all members of an organization can see all its projects. A project can be locked down to a specific subset of team members from Project Edit → Assigned Members.

Access check order:

  1. User must be a member of the project's team.
  2. User must have access to the project's organization.
  3. If the project has an explicit member list, the user must be on it.

Admins bypass project-level restrictions and always have access.

GitHub Integration

Projects can optionally be linked to a GitHub repository to display recent commits on issues. The integration requires:

  • Repository — in owner/repo format
  • Default branch — e.g. main or develop
  • Personal access token — a GitHub PAT with repo scope

The token is encrypted at rest using Laravel's built-in encryption. It is never exposed via the API.

Tags

Each project has its own tag vocabulary. Tags are created at the project level and can be applied to any issue in that project. This allows each project to define its own categorisation system independently of other projects.

Manage tags from the project issue list via the Tags button (admin access required).

Issue Reference Codes

Issue reference codes are automatically generated when an issue is created. The format is {PREFIX}-{NUMBER} where the prefix is derived from the project name and the number is sequential within the project. Reference codes are permanent — they cannot be changed after creation.

Reference codes remain valid even if an issue is soft-deleted, allowing them to be referenced safely in external systems.