How much time would you need to implement this specification?
Tags: discuss
Published: 2022-06-25 14:22:25

Since I realise some of us didn't understand [the Magic behind our support and ticket system](https://dev.to/polterguy/how-i-created-a-billion-dollar-software-system-in-a-couple-of-hours-with-hyperlambda-3oim), I want to write out the entire specification for it. Imagine you work for a consulting company, and you get a job for some 3rd party company, and they give you the following specification. How many hours of work would you need to deliver the following system in its entirety ...?

Basically, this is a specification for a support ticket system, and my question is how much time would you need to deliver it?

## Authentication, authorisation and registrations

These are the work board items related to authentication, authorisation, and registrations.

### Registrations

The system needs to provide double optin of users, allowing users to register and have an email sent to their registered email address, allowing them to confirm their email address. The email must be spoof proof, such that the link can only be used once, and once clicked, the user should be automatically authenticated and able to create support tickets.

Before the user has confirmed his or her email address, the user should not be able to interact with the system, or create support tickets in any ways.

When the user has confirmed his or her email address, the system should immediately give the user access to create support tickets, and interact with it, invoking endpoints mutating the state of the system.

This should be accomplished by adding the user to a special _"unconfirmed"_ role during registrations. As the user confirms his or her email address, this _"unconfirmed"_ role should be removed from the user, and the user should be associated with the _"guest"_ role. Only users associated with the _"guest"_ role are allowed to create new support tickets and interact with the system.

### Authentication

The system needs to provide an endpoint returning a JWT token that needs to be supplied during consecutive requests towards the backend. This token needs to contain all roles associated with the user, and is the foundation for authorisation further down in this document. This endpoint needs to take the user's username and password, and return a JWT token if the username and password combination is a match towards the system's internal users database table.

### Authorisation

As the user interacts with the system, invoking HTTP endpoints, the HTTP endpoints should be easily restricted according to an RBAC logic, making it simple to restrict access to specific endpoints according to what role the user specifically belongs to.

### User administration

The system needs to provide a GUI for administrating users, and/or roles, to add and remove users from specific roles, in addition to creating new roles. A screenshot of the latter is provided below.

![GUI for managing users](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/71yu4qx9uiczh138rjnr.png)

The system also needs to provide a GUI for browsing the server side logs of the system, such as illustrated below.

![Browsing the system log](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gt6z597r9c7nd4mh056z.png)

Besides from the above two screenshots, no GUI elements needs to be created, and only the backend HTTP endpoints required to create a custom graphical user interface should be implemented as a part of this specification.

### Security

Passwords needs to be internally stored as BlowFish hashed values in the database, with per record based individual salts to avoid Rainbow Dictionary Attacks.

The system needs to be served over a TLS connection from within a CDN network, prohibiting DOS and DDOS attacks.

Each endpoint in the system needs to _only_ allow users belonging to any one of the pre-defined roles for that specific endpoint be allowed to invoke the specific endpoint. Which roles varies according to what endpoint.

The system needs to provide CAPTCHA logic to prohibit registered users from creating scripts with their existing JWT token, to open multiple consecutive support tickets.

## Ticket system's public endpoints

The system needs to allow for invocations towards these endpoints to occur by any user belonging to the _"guest"_ role.

* Create support ticket
* Create message associated with ticket
* Get tickets (for currently authenticated user)
* Get messages (for a specific ticket, for currently authenticated user)
* Retrieve departments
* Retrieve statuses in the system
* Close support ticket

When a user invokes the _"create new support ticket"_ endpoint, the system needs to automatically associate the ticket with the currently authenticated user, in addition to sending the user an email receipt, serving as the user's future reference towards the ticket the system created for the user.

Emails should also be sent automatically as the user creates a new message and associates it with an existing ticket. The system should only allow the user who created the ticket be able to create a new message and associate with the ticket. One exception to the former statement is if a system administrator, and/or a support technician at the company wants to provide an answer to a question asked by the owner of a ticket.

When the user has been given an answer to his or her support request, he or she should be able to close the ticket himself, by invoking the _"close support ticket"_ endpoint above.

Users should not be able to neither close ticket, and/or read tickets or messages, created by other users than themselves, unless of course a support technician working for the company wants to see the currently open tickets.

The system needs to be able to filter tickets within the above conditions, and/or sort tickets, both for administrators in the system, and by users who owns the ticket(s) and message(s).

## Admin interface

The system needs to provide HTTP endpoints that can only be invoked by administrators working for the company, to allow these to answer, and/or request more information from the user. As a system administrator asks for more information about the ticket, and email should be sent to the user with the text the system administrator supplies as his or her comment.

In addition the administration interface should be given CRUD abilities on both departments, statuses, priorities, and all other database types.

## How much time would you need to implement the above if I gave you the above specification?

You can chose any programming language, and/or any framework you wish. Please answer me in the comments ...

My reasons for asking is because [I spent a couple of seconds doing 85% of the job](https://dev.to/polterguy/how-i-created-a-billion-dollar-software-system-in-a-couple-of-hours-with-hyperlambda-3oim) and two hours to deliver it entirely ...

## My delivery

[Here is the code for my delivery](https://github.com/polterguy/tickets) if you want to see how many lines of code was required to deliver it in Hyperlambda ...