Support & Issue Tracking System

An internal support desk where three roles interact with one queue. Reporters raise and track tickets, agents work and comment on them, administrators manage users and oversee the whole queue. Authentication is JWT-based and authorisation is enforced in middleware, so a role's boundaries are defined in one place rather than re-derived in each route handler.

Support requests arriving through email and chat have no state, no owner and no history. Nobody can answer who is handling a request, how long it has been open, or what was already tried.

Adding a database alone does not fix it. The moment three roles share one queue, the real problem becomes authorisation: who may reassign, who may close, who may see another person's ticket.

A support desk is a workflow tool before it is a data store. Its value is in making ownership and state explicit so that work stops being dropped.

It is also the point where an internal tool most often leaks: a missing authorisation check on one endpoint exposes every ticket in the system.

Three models — user, ticket and comment — with the comment thread attached to the ticket, so the conversation and the state live together rather than in someone's inbox.

Authentication middleware verifies a signed token and attaches the caller; role middleware then gates the route. Adding an endpoint means declaring which roles may reach it, not reimplementing the check.

Attachments are uploaded through Multer and stored on Cloudinary rather than on the application filesystem, which is what makes the service safe to run on ephemeral serverless instances.

An admin seed script creates the first administrator deterministically, so a fresh deployment has a defined starting state instead of requiring a manual database insert.

Routes are grouped by resource — auth, tickets, comments, users — with controllers kept thin and shared concerns in middleware.

Tokens are generated through a single utility so signing options and expiry are defined once instead of drifting between endpoints.

The Express application is exported through a dedicated serverless entrypoint so the same codebase runs locally as a server and on Vercel as a function.

No local disk writes: uploads stream to Cloudinary, which is a requirement rather than an optimisation on a platform where the filesystem does not persist between invocations.