Finlay.worksBareBones Ticketing manual

What BareBones Ticketing Is

BareBones Ticketing is a service desk you install and run on your own servers. This page describes what it does and how it is distributed.

What it does

People submit requests. Staff work those requests as tickets. The product decides who can see which tickets, moves each ticket through the stages you configure, and records what happened.

Five things make up the product:

Request intake. Requesters submit requests through a Service Catalog form or through Quick Ticket. It is open to internal users and refused to Customer Portal requesters. Each request becomes a ticket owned by one department. An inbound mail bridge exists in outline, but it is not a supported intake path in this 1.0 release and cannot be made into one — it waits on a mail gateway that has not been built.

Department-scoped work. Every ticket belongs to a department. A person sees a department's tickets because a group they belong to is mapped to that department, at a View, Work, or Admin level. A person with no mapping to a department does not see that department's tickets. Agents work tickets from the queue within the departments they are mapped to.

Configurable workflows. A workflow is a set of statuses and the permitted transitions between them. A System Administrator defines statuses, workflows, transition rules, service-level agreement (SLA) policies, and the business calendars an SLA target can be measured against. Services bind to a workflow and an SLA policy, so different kinds of request move differently.

Project-based work. A project is a first-class record for managing a body of related service work. It has its own reference, name, owning department, workflow, and status, and tickets are linked to it. A project has staffing slots, and a role-mapping rule can make whoever fills a slot the owner, a watcher, or a participant on the project's tickets. Linking a ticket to a project does not by itself reassign it: association, staffing, and role-mapping are separate settings that must line up before project-linked routing takes effect.

An audit record. The product writes an append-only record of supported events and provides administrative surfaces to review and export it. Append-only means recorded events are not edited or deleted in place. This is a record you can review; it is not a validation, certification, or compliance result.

How you get it

There is no hosted version. BareBones Ticketing runs on a Windows Server or Linux host that you provide. By default the product installs and manages its own PostgreSQL database — a server instance on Windows, a bundled container on Linux — so you do not have to supply one; you can instead point it at an external PostgreSQL database you already run. Either way you own the server, the database, backups, restores, upgrades, network and certificate setup, and every access decision. See PostgreSQL for the two database modes. See Editions for licensing and current package availability.

What it does not do

Two limits catch readers who assume otherwise. A licence controls whether the product runs; it grants no person access to any ticket. Navigation is drawn from role, not from a permission check; seeing a menu item does not mean the action will be permitted. Both are covered in Roles and access.

Product-wide limits are listed in Limits and scope.