Building a Ticketing App: From Request to Resolution

A support request needs somewhere better to live than a message that gets buried halfway down a conversation. The Ticketing project gives those requests a place to be submitted, assigned, discussed, and tracked.

The app has two distinct views. Requesters can submit tickets and follow their own conversations. Agents can work across the ticket list, search and sort it, update metadata, and manage the people and categories behind it. Public replies are part of the requester conversation; private notes are for agents. The application filters those notes on the server before returning ticket data to a requester.

The recent work has focused on making a growing ticket list easier to use. Requester search matches names and email addresses. Category search can find a term anywhere in a hierarchy, so someone looking for a printer issue does not have to work through every branch of a giant dropdown. Category IDs stay stable when a category is renamed or moved, preserving the connection to existing tickets.

Mobile behavior has needed attention too. Smaller category rows, expandable editing controls, and fixes for iPhone form zoom all address the difference between a page that technically fits and a page someone can comfortably use.

The app uses PHP and JSON files. Each installation maintains its own tickets, accounts, directory, and categories, separate from the source repository. That makes preserving runtime data during deployment part of the design.

Release 1.7.3 adds Microsoft 365 email setup documentation. Actual outbound notifications and inbound email replies remain future application work. Passwordless test mode is also a development convenience, not a finished production identity system.

This project explores the whole support workflow. The ticket form is the beginning; the interesting work is everything needed to keep the conversation organized afterward.

Explore the project on GitHub