I built an open source ticket system for my work place and it was pretty trivial.
Getting started with a project is a trivial task using all the good examples on the flask website.
My workplace is all about emails, everything that happens is first made known through email. However, everytime something I, as a tech, have to know about, I also get an email that looks just like all the other ones.
While I quite like that everything can be organized in Outlook, I find it quite tideous sorting through my emails all the time, just sorting by "This seems to be a tech problem" or "This is an internal newsletter." Theres multiple techs at my workplace, and no matter how hard we try, we can't get the users to just write "Ticket" somewhere in the email subject.
That is why we all decided to spin up some sort of Ticket System to make sorting out emails a bit easier and to give the users a bit more feedback about their tickets.
Why didnt I just use a prebuilt ticket system then?
My Workplace has quite the weak server infrastructure and internet connection. While we hope to get some new hardware later this year, spinning up another Docker container on our server just wasn't possible.
This is why we needed to spin up another box for the time being. Because this ticket system was just a small thing to test for a while until my boss said that they wanted this ticket thing to continue, we didnt have any allocated hardware. I needed a small and not blazing fast, but responsive server, so I my immediate choice fell on a Raspberry Pi SBC.
The Raspberry Pi runs on an ARM chip and newer models like the Pi 3 and Pi 4 are such hard-thinking powerhouses that they even need fans. In essence, the Pi would be able to run simple ticket systems just judging by raw computing power, but the thing is: It's an ARM based CPU. The only problem: I couldn't find any open source, free to host yourself, ticket systems that would be able to run on an ARM CPU.
I think that this is quite sad, as a Raspberry Pi (as long as it isn't a compute module 4) is really easy to obtain, and an easy way to get a simple linux host up and running, even during a global chip shortage.
This is why I started my own journey, building an easy to use ticket system named SimpleTicket that has minimal system requirements, yet runs everywhere without all the huge problems of cross-compilation.
Laying down the first bricks
When I started this project, I immediately was sure that I wanted to build the backend using Python, as I recently had a lot of problems just installing Node.js on my Raspberry Pi, resulting in me having to rebuild the filesystem after some interesting behaviour of the APT package manager. So Python 3.7 it was, as I heard some friends talk about Python 3.8 not being that stable and Python 3.9 not widely adopted yet. And I mean, upgrading to a later version of Python has not once been an issue to me yet, so I can probably do it in the future if the need arises.
I also previously gained a lot of experience with Flask when working on pilearn.de and the open source version openLearn with luap42. This is why my immediate choice for the "proof of concept" (aka. the version that will probably outlive me in this company) fell on Python with Flask.
Starting out, I did the usual things for a software project. Make a private repository so nobody sees my spaghetti for now, start the project up in VSCode and get on coding.
I decided to start out by using a SQLite Database which is compatible with Flask's SQLAlchemy module. One question though: Why doesnt SQLite have a drop column function? After writing a first mockup of the model.py file for SQLAlchemy and having to change something about assigning users to a ticket (removing the column because its just 2 techs here) the migration failed.
The rest was pretty much smooth sailing, except for the usual problems with databases getting out of sync, but lets just blame caching for that.
A field test
After creating the groundwork to make a ticket system that you can use in yur web browser, I got approval to work on it during work hours. My workplace and I are now testing all the functions that I have currently implemented, and for now its pretty stable.
My plan for the future of SimpleTicket is to improve functionality and make the UI more polished. If anybody has a great idea on what to add to SimpleTicket, please feel free to drop a GitHub Issue on my repository so I can address it as fast as possible.
I also want to create a new installation process and some better functionality for administrators, for example a livechat, automated page refreshes and a better design.
Help me by collaborating
on the SimpleTicket GitHub Repository.