Pet-project for learning or how I wrote Helpdesk alone
Good day! My name is Anton, I work as an engineer in the maintenance and administration department. I started studying programming languages quite recently, although I always really wanted to.
What started it all.
The story began about a year and a half ago. Wandering around the expanses of the network, I stumbled upon some kind of programming course (actually quite well-known), I thought that I had long wanted to migrate from support to developers and signed up for the trial part. The course was on Python programming. I quickly went through the introductory part, learned some basics and realized that it was interesting. Then I decided on my own, with the help of materials from the network, to improve my skills.
The first thing that came to my mind was to write a desktop program for monitoring IP cameras. The logic was as follows, if there is a ping to the camera, then everything is fine, if otherwise, something went wrong and you need to notify a specially trained person about this (for efficiency, preferably in Telegram). The task is simple, but useful for a learning programmer. Based on the PyQt5 framework. Of course, I had to suffer a little with multiprocessing and freezing of the application, but in the end the application was written and transferred to the use of a video surveillance specialist. He was delighted and has been using the app ever since. The project is finished, but I want to develop further and somehow help my colleagues. It was then that the idea came to mind, to write your own Helpdesk.
problem and idea
Our IT department employs only 10 people – this is a technical service hotel, a development department and a communications department. Everyone, to some extent, is engaged in technical support for users. At that time, all applications came, either by e-mail or by phone. It seemed to me that this is terribly inconvenient and poorly controlled:
there was no clear idea of the current tasks
many applications could simply be forgotten
for users it is not very clear in what state their application is now
there is no order of execution, everything is according to the principle, “who has time, that and slippers”
there is no prompt notification of new applications, as a result of which the phone is constantly torn, from user calls
Previously, I already had experience using Helpdesk systems based on:
Microsoft SharePoint 2007
OTRS
The first did not work for a long time, due to the inconvenience and lack of a person who would support him. The second one was raised and configured by me, but for some reason the manual was never implemented. Attempt number 3, I thought, and started designing my own helpdesk.
Help desk design
So, initial data:
There are about 500 users in the organization, it is planned that all of them will use the helpdesk
10 employees, in 3 departments, who will also use the helpdesk in their work
All users are divided into groups, by companies and are included in one domain (Active Directory)
System users need email notifications (for employees still in Telegram)
The system will be used only within the enterprise
Started with a basic schema:
That is, the service, at a minimum, must have:
pass-through authorization through a domain controller, application form,
user Interface,
employee interface,
be able to notify about new applications and the result of their implementation,
generate reports on requests, for a certain period of time, grouped by companies, departments, employees, etc. And unload it, for example, in Excel.
Since I started learning Python, it was decided to do it all in Django. First of all, I began to look for and study such systems, and what they include. The resulting structure looks like this:
Forward to knowledge
According to the DB schema:
The user has a primary profile and an additional
Each application is associated with a user
You can leave comments on the application.
You can attach a file to your application.
Each user has access to notifications about their applications
Based on this, the corresponding models were created and migrations were carried out.
Authorization
Since all users in the enterprise work on computers located in the domain and are authorized on computers using Active Directory, authorization on the helpdesk must also be through Active Directory. And this should happen without user intervention. That is, if the user logged into the computer under his account, then when opening helpdesk, he will automatically log in.
Having read the information on the Internet, he set to work. For this functionality, I needed:
Nginx built with the SPNEGO module
additional libraries for Django – django-auth-ldap and django-remote-auth-ldap
I also wanted information about users stored in Active Directory (company, department, phone, etc.) to be automatically pulled into the user profile. Luckily, this was fairly easy to implement using the same Django tools and signals.
How to set it all up there is information on the Internet. It works for me like this:
The user visits the site
Nginx authorizes it, and passes the REMOTE_USER parameter to Django
If there is no such user yet, Django uses django-auth-ldap to create a new account. If there is, it verifies that the information in the account and Active Directory match and updates it.
As a result, users get to helpdesk already authorized.
Create an application
The next step was the creation of the application itself. Started by creating an application form. It should be fairly simple and easy to understand for the user. I settled on this application form:
The applicant, department and phone are automatically pulled from the user’s profile (if there is such information there). The user only needs to select a category, add a description, if necessary, attach files. In my opinion, it turned out quite simply and clearly.
List of all applications
I decided to make a list of all applications in the form of a table with some filters.
This is how the interface of all requests in the user account looks like. The user sees only applications created directly by him.
In the employee’s office, the table looks a little different, with a little more information.
Employees see only those applications that are intended for their department. This means that an employee from the development department will only see requests sent to the “Development department” category.
There is also a group for managers, they see applications of all categories. And if a user accidentally sent an application to the wrong department, the manager can correct it.
Editing an application
It was decided to display editing the application using a modal window, in the form of ordinary forms.
For employees and managers, the form is more meaningful and with more editing rights:
Notifications
When creating (changing) an application, it was necessary to send notifications to employees of the relevant departments and users by e-mail. Depending on the category of the application, the notification is sent only to a certain group of employees.
For email notification mail used the standard send_mail library. Sometimes there was a hangup of the interface, during any actions with the application. I had to dig and as it turned out later, this is due to the long response of the mail server. I had to look for a way out, and he was found in the face of Celery. Set up Celery in such a way that it creates tasks for sending and forms a queue. This allowed the interface not to freeze when the mail server responded for a long time and to work more stably.
For greater efficiency, a notification was implemented for employees in Telegram using the pyTelegramBotAPI library. Example notification below:
As soon as changes occur with the application, the backend instructs the bot to send a notification to the group in Telegram corresponding to the department. Groups in Telegram for the respective departments were pre-created.
Application reports
For reports on applications, a separate page with a form was allocated:
After selecting the parameters, a report is generated that can be downloaded in Excel format. Access to reports is available only to heads of departments.
Introduction to work
Upon completion of the work, as far as I could test the system. Colleagues also had to work as testers. As a decent developer, I tried to fix all the bugs that I found.
With the help of group policies, I scattered the Helpdesk shortcut on the users’ desktops and wrote the instruction “How to use the Helpdesk”
The start of Helpdesk has been scheduled. On the appointed day, instructions were sent to everyone by e-mail. Since then, the application system has been working. At first, out of habit, users tried to leave requests by phone and by e-mail, but over time, almost everyone got used to it and began to use Helpdesk.
Conclusion
On this, the first part of the Pet-project for training was completed. The Helpdesk system turned out to be quite working, people use it, many even like it. I have moved a little towards development and it pleases.
I am writing for the first time, so do not judge strictly.
PS Almost a year after the launch, a lot has already been redone, changed and added. The following technology stack is currently in use:
Nginx – as a reverse proxy server, with SSO authorization in Active Directory,
Django (DRF) – backend with LDAP authorization,
Django Channels – for working with WebSocket,
Celery – for job queue,
Redis,
PostgreSQL,
React (React Redux) – as a frontend,
Docker (Docker-compose) – to build all of the above.
