github.com/mortenterhart/trivial-tickets
Trivial Tickets is a basic implementation of a support ticket system in Go. Customers of a company can easily create tickets with the form on the home page (see the screenshot below) and display the created tickets over a static permalink. The author of a ticket is informed about every action the ticket experiences by an email written to his email address.
Registered users are the assignees of the system and work on the customer's tickets. They can log in and off the system and assign a ticket to themselves or to other users. An assignee can only edit information on those ticket that he is assigned to. He can release his tickets, add comments to it or change the status of the ticket. It is also possible to merge two tickets to one, but only if the customer and the assignee of both tickets match. Additionally, an assignee may indicate that he is on holiday. In this case, tickets cannot be assigned to him.
The ticket system offers an E-Mail Recipience and Dispatch API for a mailing
service to interact with the system. A request with the properties from (the
sender's e-mail address, i.e the customer), subject (the ticket's subject) and
message (the actual message) set can be delivered to the server in order to
create new tickets by mail. If the subject contains the ticket id of an already
existing ticket in a special markup the e-mail creates a new answer to this
ticket instead of a new ticket.
Likewise, the mailing service can fetch e-mails created by the server on special events (such as creation of a new ticket or update of a ticket). The server then sends back all e-mails remaining to be sent to the customer. After the service has sent the received e-mails it can confirm the successful sending of the concerned e-mails by sending a verification request to the server. This is done for each e-mail by applying the id of the certain mail to the request. If the server can ensure that the respective e-mail exists the mail can be safely deleted and the verification result is returned to the service. More information on the Mail API and its functionality can be found on :book: Mail API Reference.
The repository contains a command-line tool which serves as simple example for an external mailing service. Although it cannot send or receive genuine e-mails it can communicate with the mail API of the server. The user can write really simple e-mails with e-mail address, subject and message to be sent to the server. Alternatively, he may retrieve all server-side created e-mails that are print to the console then. All fetched e-mails are verified against the server who can delete the mails then safely.
Consult the :closed_book: User Manual for more information (currently only available in German) or alternatively checkout our :book: Wiki Pages.
Preview of the Trivial Tickets Homepage
Coverages for the different packages and files as evaluated by codecov.io
The coverage sunburst is a graph of the project in a multi-level pie chart. The color represents the coverage of the project, folder, and files. The innermost circle is the entire project, the next slices are folders leading to the outermost slices which are files.
To install the Trivial Tickets ticket system, first ensure you have a working Go
environment installed. Go version 1.7 and above are supported. Set the GOPATH
environment variable to your desired location and then execute
go get -u -v github.com/mortenterhart/trivial-tickets
This command requires git to be installed. It downloads and installs
all project dependencies to your setup Go workspace. For more information
on how to set the GOPATH environment variable accordingly visit Setting
GOPATH from the Go Wiki.
The ticket system is now installed under
$GOPATH/src/github.com/mortenterhart/trivial-tickets.
:warning: Please do not use the go install command as it puts the binary to
$GOPATH/bin and the default file and directory paths get incorrect.
To build the ticket system, you can run the following command from the repository's root folder:
go build ./cmd/ticketsystem
Make sure to build the executable from the mentioned directory so that the
default paths still apply correctly. Your binary should be located at
ticketsystem or ticketsystem.exe depending on your operating system
then which can be executed with
./ticketsystem [options]
A more convenient way to start the server is to use the start scripts in the root directory. Run
./startServer.sh [options]
or startServer.bat on Windows systems. The same applies to the command-line
tool (./startCLI.sh and startCLI.bat). See the :paperclip:
Configuration section for a list of valid options.
The unit tests for the different components of the server can be executed with the following command from the root directory:
go test -v ./...
This executes all tests in all sub-packages. For details about the coverage use
the option -cover.
To generate a coverage report about one or more packages, use the provided
script coverage_report.sh. Run
./coverage_report.sh
to generate a coverage report of all sub-packages with default options. The report will be rendered as HTML and opens in your default web browser.
Try ./coverage_report.sh --help for a complete list of options or
alternatively consult this :book: Wiki page.
The server will create new tickets and mails on certain events in the configured
directories (by default files/tickets and files/mails). There are three
tickets predefined in this repository. All other tickets and mails are ignored
by Git.
To cleanup all untracked tickets and mails, i.e. every other file except the predefined tickets, use the following script:
./cleanupUntrackedTickets.sh
The script will prompt for confirmation before removing any files unless the
option --force was given. If the confirmation was successful it will remove
all ticket and mail files not tracked by Git. This is done by the git clean
command.
Try ./cleanupUntrackedTickets.sh --help for a list of available options or
alternatively checkout this :book: Wiki Page.
The ticket system main executable
ticketsystem.go offers the following
configuration flags. They can be used to alter the default configuration of the
server and the logger. No option is required since every option has a meaningful
default value.
The usage of the executable looks like following:
./ticketsystem [options]
The following server options can change important connection settings such as the port and file or directory paths to important resources.
-port <PORT>Specify the port on which the web server will be launched. On startup a message
with the server's URL will be shown. The PORT is a 16 bit unsigned integer (0
< PORT ≤ 65535) and should not be used by another process. If the specified
port is blocked the server throws an error at startup.
Default: 8443
-tickets <DIR>Configure the directory where the tickets will be stored. The DIR argument can
be an existing directory with active write privileges, otherwise it is created
on startup automatically. Note that the path has to be relative to the current
working directory. The *.json files in this directory have to contain valid
JSON content.
Default: ./files/tickets
-users <FILE>Change the default path to the users file. The FILE argument has to be an
existing JSON file with user definitions. Note that the path has to be relative
to the current working directory.
Default: ./files/users/users.json
-mails <DIR>Specify the directory where new mails created by the server will be saved. The
DIR argument can be an existing directory with active write privileges,
otherwise it is created on startup automatically. Note that the path has to be
relative to the current working directory. If DIR already contains *.json
files they have to contain valid JSON format.
Default: ./files/mails
-cert <FILE>Set the path to the SSL server certificate. The FILE argument has to be an
existing file with a valid SSL certificate. Note that the path has to be
relative to the current working directory.
Default: ./ssl/server.cert
-key <FILE>Set the path to the SSL server key. The FILE argument has to be an existing
file with a valid SSL public key. Note that the path has to be relative to the
current working directory.
Default: ./ssl/server.key
-web <DIR>Change the root directory of the web server. The DIR argument has to be an
existing directory and should match the templates path and static paths pointing
to the server resources (such as /static/js/ticketsystem.js).
Default: ./www
The logging options alter the way messages are logged to the console.
-log-level <LEVEL>Specify the level of logging. The given LEVEL can be one of the following:
info: display all log messages (recommended)warning: display only warnings, errors and fatal errorserror: display only errors and fatal errorsfatal: display only fatal errors (not recommended)Fatal errors are always logged and cause the server to shutdown directly.
Therefore it is not advised to set the log level to fatal.
Default: info
-verboseEnable verbose logging output (includes information about package path and function name, filenames and line numbers on every log message). For better readability, the package and file paths are trimmed to the last component, so leading directories will be stripped.
Default: false
-full-pathsDisable the abbreviation of package and file paths. Paths are written as is to
the log. This option is compatible to -verbose.
Warning: This will extend log messages a lot making it harder to read. Depending on your screen size the messages will probably not fit on the screen.
Default: false
The help options provide information about the usage of the ticket system and its flags.
-h, -helpPrint a help text with information about the flags and exit.
The command-line tool can be used to interact with the server's E-Mail Recipience and Dispatch APIs. A user can create an e-mail which is sent to the server and has to supply a valid e-mail address, a subject and the message. The created mail is then delivered to the E-Mail-Receive API of the server where a new ticket will be created out of this mail. Optionally, the user may supply an existing ticket id to create a new answer instead of a new ticket.
Another option is to retrieve all created e-mails on server-side. The mails are fetched from the server and output to the console. For each fetched mail the command-line tool confirms the successful sending of the e-mail by calling another API to verify the sending. The tool cannot send genuine e-mails of course, but the sending of the mails is simulated. After each mail is verified to be sent correctly the server deletes these mails from cache and from file system.
The command-line tool can be built in the same way than the server by executing
go build ./cmd/command_line_tool
from the project's root directory. A better option is to use the attached start scripts for UNIX and Windows systems. To use these, run
./startCLI.sh [options]
or startCLI.bat on Windows, respectively. Options can be appended to the call
and they are delegated to the command-line tool. See the following section for a
list of available options.
The command-line tool can be run in the following way:
./command_line_tool [options]
If the command-line tool is started without options, the user is guided by an interactive menu. Otherwise he has to supply the required options by himself and there is no prompting for user input.
In the following the available options are listed.
The following options can be used to configure the client's connection settings.
-host <HOST>Use another host name or IP address for the server the client is connecting to.
Default: localhost
-port <PORT>Specify the port the server listens to. The PORT argument has to be a 16 bit
unsigned integer (0 < PORT ≤ 65536) and has to match the server port.
Default: 8443
-cert <FILE>Use another SSL certificate for the connection to the server. The FILE
argument has to be an existing file with a valid SSL certificate. Note that the
path has to be relative to the current working directory.
Default: ./ssl/server.cert
The fetch options configure the way e-mails are retrieved from the server.
-f (fetch)Fetch the server-side created e-mails from the server. If this option is set, there will be no interactive prompt, but only the messages are retrieved.
Default: false
The submit options are used to specify e-mail properties for a direct submission of an e-mail without user inputs.
-s (submit)Use this flag to directly submit a message to the server without prompting. The
mail properties are set by the -email, -subject and -message flags and are
required. If the -tID option is specified with a valid ticket id a new answer
will be created instead of a new ticket.
Default: false
-email <EMAIL>Specify the sender's e-mail address used for the creation of a new e-mail. The
EMAIL argument has to be a valid e-mail address. Only applicable in
conjunction to the -s flag.
Default: empty
-subject <SUBJECT>Specify the subject of the new created ticket or answer. The SUBJECT argument
should not be empty. Only applicable in conjunction to the -s flag.
Default: empty
-message <MSG>Specify the message for the new created ticket or answer. The MSG argument
should not be empty. Only applicable in conjunction to the -s flag.
Default: empty
-tID <ID>Specify the ticket id of an existing ticket to append the message as a new
answer to this ticket. This flag is optional and if it is not set or if the
ticket id is invalid, a new ticket will be created. Only applicable in
conjunction to the -s flag.
Default: empty
The help options provide information about the command-line tool and its provided flags.
-h, -helpPrint a help text with information about the flags and exit.
github.com/stretchr/testify/assert
and github.com/pkg/errors.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.
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.
flag).Deadline: 10th January 2019
The following has to be supplied:
The program draft is rated after the following criteria (with descending emphasis):
go test -cover)pushci.Currently the user manual is only available in German language. It consists of a guide to install the ticketsystem and the command-line tool and how to execute it the first time. The manual further explains how to configure the server and the command-line tool using command-line flags and documents them. It is also explained how to use the included website and the command-line tool to interact with the web server. The user manual includes a reference about the offered Mail API and tells which constraints a client has to take account of when communicating with the server.
Read the manual here: :closed_book: Ticketsystem User Manual DE (German)
The Mail API reference and all information about it can be found on this :book: Wiki Page.
The FAQ of the Trivial Tickets Project can be found on this :book: Wiki Page.
This project is licensed under the GNU General Public License Version 3. See the License page in the Wiki or http://www.gnu.org/licenses for information about redistribution.
Trivial Tickets Ticketsystem
Copyright (C) 2019 The contributors
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses.
FAQs
Unknown package
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
Security News
Research
A supply chain attack on Rspack's npm packages injected cryptomining malware, potentially impacting thousands of developers.
Research
Security News
Socket researchers discovered a malware campaign on npm delivering the Skuld infostealer via typosquatted packages, exposing sensitive data.