Requirements #

1. Non-functional #

1. Third-party packages are not allowed. The only exception are packages which simplify the tests and error handling. Recommended are github.com/stretchr/testify/assert and github.com/pkg/errors.
2. All source files and the PDF file must contain the matriculation numbers of all team members.

2. General #

1. The application has to administrate only one mandator or project, respectively. More ticket systems on the same server are not required.
2. The application should be executable on Windows and Linux.
3. All major browsers such as Internet Explorer 11, Firefox, Chrome and Edge should be supported in its current version. This requirement is met the easiest if complex JavaScript/CSS is avoided.

3. Security #

1. The website should be only accessible through HTTPS.
2. The access for the assignees should be protected by a username and a password.
3. The passwords may not be saved as plain text.
4. Password salting should be used.
5. All credentials should be saved in one common file.

4. Ticket #

1. A ticket contains
   • an unique identifier
   • a subject
   • the status of the ticket (Open, In Progress and Closed)
   • the id of the assignee if in state “in progress”
   • some entries
2. An entry contains
   • the creation date
   • either the customer’s email address or the assignee’s name
   • message of the entry

5. Ticket creation on the website #

1. It should be possible to create a ticket on the website.
2. The ticket can be created without authentication.
3. The following should be recorded:
   • email address
   • subject line
   • the message of the ticket

6. E-Mail Recipience over a REST-API #

Later, a service should be available which hosts one or more accounts for ticket creation. The service should retrieve the e-mail account and deliver all incoming messages to the ticket system. The e-mail service is not part of the actual task.

1. There should be a function which can receive messages from the external service.
2. The function should have the following parameters:
   • e-mail address
   • subject line
   • the text of the message
3. On call event, the application should check if the message belongs to an existing ticket.
4. If a ticket is found
   • the message should be appended as new entry
   • and if the ticket has the status “Closed” it should be reset to “Open”.
5. If no existing ticket is found a new ticket should be created out of the message.
6. There should be a simple command-line tool which can send messages to the server.

7. E-Mail Dispatch over a REST-API #

Later, a service should be available which hosts one account for message delivery. The service should fetch created e-mails by the server, send these messages and then verify the sending. The e-mail sending service is not part of the actual task.

1. There should be a function which can deliver all e-mails remaining to be sent.
2. There should be a function where the service can tell the server which of the e-mails are already sent.
3. An E-Mail-Ping-Pong should be avoided (as of absence assistant).
4. There should be a simple command-line tool which can output remaining e-mails to the console.

8. Editing of tickets #

1. The editing of tickets should only be able on the website.
2. Assignees should assign a ticket to themselves.
3. Assignees should be able to see all tickets which are not assigned yet.
4. Assignees should be able to release tickets after assignment so that other assignees can work on the ticket.
5. An assignee should be able to assign a ticket to another user.
6. If an assignee of a ticket writes a comment he should be able to choose whether the comment is visible to the customer or only to other users. If the customer is chosen an e-mail will be generated by the new comment.

9. Storage #

1. The tickets are saved to the file system including the complete progression of the ticket.
2. Tickets should not be saved in one common file.
3. There should be an adequate caching implemented. That means a request should not cause reading all files again.

10. Configuration #

1. The configuration should completely occur with command-line options and arguments (see package flag).
2. The port should be settable by a flag.
3. Hard coded absolute paths are not allowed.

11. Execution #

1. If the application is started without arguments it should choose meaningful default values.
2. Non-existing, but required directories should be created where applicable.
3. Although the application is intended to support HTTPS and the corresponding required certificates, it can be assumed that suitable certificates will be provided. You can use a self signed certificate for your tests. It is not necessary to create certificates at runtime. Likewise no Let’s Encrypt connection is required.

Optional Requirements #

1. Holiday mode
   • An assignee can be in a holiday mode.
   • If an assignee has this mode enabled no tickets can be assigned to him.
2. Merging tickets
   • It should be possible to merge two tickets to one ticket.
   • All entries of one ticket should be added to the other ticket.
   • The second ticket should be deleted.
   • This should only be possible if both tickets have the same assignee.