Week 7

Project: Ticket Tracking System

Sending emails

Design document

Technical interview

Back end Track

Ticket Tracking System

Overview

You'll design and build the backend for a new ticket tracking system — the kind of tool teams use to log, assign, and follow up on work, like Jira, Trello, or GitHub Issues. A ticket tracking system lets users across different projects manage their tasks, bugs, and other to-dos. Each ticket represents something that needs to be done and holds the key information about it: what the work is, its current status, and who is responsible for it.

Jira - a popular ticket tracking system

You'll build a REST API that will allow you to manage tickets, users and projects within the system. Your API will manage users, tickets and projects, store everything in a SQL database, and email the people assigned to a ticket whenever it changes.

Entities

<aside> ❗

You will be modeling three things. These are the fields the business cares about — how you turn them into tables, keys, and relationships is your decision.

</aside>

1. User

Represents a single person who is using the system. Fields:

1. name - at least 3 characters, required
2. email - valid email format, required

There is no need to implement ****an authentication system (login, passwords, etc…)

2. Project

A project represents an area of work that multiple tickets can be connected to.

Must have fields:

1. name - at least 3 characters, required

3. Ticket

Must have fields:

1. Title - required
2. Description - optional
3. The Project it belongs to - required
4. Status - required, Must be one of the following values: open, in progress, closed .
5. Assigned users - a list of assigned users, can be empty.
6. Creation date - required, will be set automatically by the system.
7. Update date - optional (Empty if there were no updates), will be automatically set by the system.

<aside> 💭

In plain terms:

• A ticket belongs to one project.
• A ticket can have several assigned users, and a user can be assigned to several tickets. </aside>

Product Requirements

<aside> ❗

These are capabilities, not endpoints. You decide how they map to resources, URLs, and HTTP methods — and your design should use GET, POST, PUT, and DELETE where each is appropriate.

</aside>

Users

• Create a new user
• Update an existing user
• Delete a user
• List all users
• Get a single user with their details.

Projects

• List all projects, each showing its name and its number of tickets per status (e.g. 10 open, 5 in progress, 30 closed)
• Creating, Updating or Deleting projects is not required to implement.

Tickets

• Create a new ticket
• Update a ticket title, description, status or project
• Add an assignee to a ticket
• Remove an assignee from a ticket
• Get a single ticket
• Search tickets:
  • Search by text matching the title or description
  • By Status
  • Multiple search filters can be applied with AND logic. (e.g: all open tickets with the word ‘Bug’)
  • No filters will return all tickets

Note: Deleting ticket is not possible in the system.

Email sending

Each time a ticket is updated, send an email to all the assignees of that ticket to let them know what have changed. For example:

Ticket #123 updated:
Title: "Fix the database"
Status: "In progress"

Current assignees: Max, Dave, Yaris.

It is up to you to handle the case when sending an email fails

Validations

You are responsible for implementing validation checks according to the specification above. In addition to extra validations that are not explicitly mentioned such as:

• Check required fields and minimum length strings
• Check that the user exists before assigning them on a ticket

<aside> ❗

You are responsible for protecting your API and database from bad or invalid input. Make an effort to validate everything before saving the information in the system.

</aside>

Technical Requirements

Tech Stack

• Use the latest Java LTS version with Spring Boot
• Use a PostgreSQL database in a Docker container
• Manage your codebase with Git and Github
• Use ENV variables to store secrets

Database

• Define proper primary and foreign keys
• Assigned proper data types from Postgres
• Design a database according to 3N
• Create at least one Index that may be useful

Architecture

• Split your application into Controllers, Repositories, Services, Models etc…
• All requests and responses must be in JSON format.
• Design a clean REST API according to the best practices we learned: proper HTTP status codes, headers and paths

Tests

• Write at least 3 integration tests for at least one endpoint.
• Write at least 3 unit tests for business logic.