How we wrote helpdesk (part 2)

In continuation of part 1 , we decided to write an article about how we reached a “new level” in creating a web product. I want to clarify right away that this is not exactly a helpdesk, which is based on the creation of applications by clients (although this possibility is present), but is more aimed at the internal work of an organization or IT department. I also want to remind you that the system was created specifically for our requirements, so it is not better than others, but not worse. It is simply “different”, which has its own functions for specific tasks and may take its rightful place in the general world of products that make the IT world better.

Foreword

After the release of the article about the opensource version of the product, I saw a return on the project. The first is of course github . Thanks to him, I saw that they began to pay attention to the code and functionality: someone criticized, not offering anything in return, and someone made good comments. In any case, there was a return and it had a positive effect.

1. We found out what functions people want and then some (necessary in our opinion) applied in themselves.

2. Found bugs and fixed them.

3. A list of the necessary appeared, which became the “development route” - ROADMAP.



There was an acute question about the organization of the workflow. I realized that it was difficult to code, communicate on development issues and check / test found bugs. The project was developing more and more and at some point the thought came that our contribution to the project exceeds our expectations. We decided to receive a symbolic reward.

Criticism

There were many critics that abandoned the project and offer only the paid version. But we always made a compromise - get up in the line, help, be part of our team, make a contribution and get a reward for it. If there is no opportunity to buy a product, then we ask: how can you help the development of the project? And then there was a barter. People offered ideas, functionality, implementation, and we gave the distribution to use and worked.

Product concept

First of all, we sought to make the system simple, convenient and functional. It was these words, as the basis, that made us write our system, and not take ready-made or paid.

To understand how the system is still used, it is best to give a life example when there is a boss who has several subordinates. These people work according to the principle - perform the task or pass it on to another. That would control the execution of tasks and serves just such a system.

This is good because:

1. See the result of work and the workload of each employee

2. All actions are logged (if there is a task from the authorities to format the HDD, then you do not need to prove anything)

3. Create reports for any period and see who did what



Thus, the use of our system has already found in government agencies, it-departments, agro-industrial enterprises, technical support services, delivery and other areas. According to its purpose, the system focuses on the organization of work with applications / tasks within a department or corporation, but with the ability to access the system of clients with limited rights and functionality. It looks like this: we are an IT department, we work with the tasks that the head or coordinator creates for us. These tasks can also be created by the system users themselves, receiving them from customers by telephone. Clients themselves can also create applications from their personal account.



')

What is under the hood?

The code has been streamlined more or less to the concept of MVC and optimized. As before, the basis of the system is:

- JS-view (responsible for the actions on the user's page and the processing of a particular UI element)

- Actions php file (accepting actions from ajax requests and processing them, a kind of API part)

- Functions and classes (on the basis of which both actions and other system files work)

It was this structural approach to the organization of the project that was invented by me. Using NodeJS, a web socket layer was added that constantly checks the event queue. Several scripts that run on a schedule and are responsible for the queue of notifications and the transfer of applications to the archive. The version update system allows you to update the entire system in one click, while creating a backup copy of the current system. Detailed description of the system below.

What exactly made us switch to paid development?

Customer / User Structure

Previously (in the opensource version), the system had two logically different entities and tables. On the one hand, it was convenient because full-fledged users of the system were in one place, and clients without access and rights - in another. But in the new version we have organized the possibility of access to the system for regular customers to create applications. Thus, the system allows you to separately introduce personal account templates of your own CRM system into ours and integrate two products.

Any user can connect to LDAP, and assign certain rights to it. Quite often we are transferring thousands of user accounts to zenlix from the existing Active Directory, so that customers can create applications using their AD login / password.



NodeJS and notifications - earlier, users received pop-up notifications due to a timer in the js code, which every N-seconds of time sent an ajax request with a key to check for new user events. Now, thanks to the raised nodejs / socket.io server, we can receive the messages from the server with the necessary commands and process them on the client side. This is how the pop-up event system works:

- new application

- commented application,

- locked / unblocked application,

- completed / not completed application,

- chat message.

This significantly reduced the load on the server.



Notification system

This is not only email notifications, but also with the help of third-party services such as pushbullet, sms, jabber and others. We have moved from procedural execution of sending letters on user actions to logically-planned. Notifications should be understood as sending letters and launching functions of libraries of third-party services. As a result, after each completed action with an application that led to sending notifications, the user waited for sending notifications (letters, pushbullet) and others, to all participants (and if there are about 20!), Then creating an application for a department (sending notifications ) it took so much time that the script gave timeout.

Today, we already have a system that processes a huge number of notifications for a short period of time, has a check on how to send notifications. This works thanks to the queue system. All events are accumulated in the database table, which is checked at one-minute intervals, using a script that sends all notifications to all services. Thus, sending notifications works asynchronously from user actions with the UI.



The template was chosen from the AdminLTE series and as stated in the description: “Free Premium Admin Control Panel Theme That Is Based On Bootstrap 3.x” :) It allows the system to look great on various devices and has a rather pleasant set of UI elements that please the eyes people constantly working with the system.



Task Manager

This is something that did not want to do, but made us because of the persistent client. Thanks to this functionality, we have the opportunity to create an application with certain parameters and plan its creation with the necessary frequency. This applies to typical regulated tasks such as maintenance of equipment or the creation of backup copies.



Reports and charts

We were so often asked to write and display reports on certain criteria, that we simply combined the most frequent requests into several informative reports. Now we can watch the statistics

- for specific users for a certain period,

- by selected departments for the period,

- general statistics of the entire department.

In addition, each user of the system is available and personal statistics.



Update system

The user in the admin menu clicks on the button, as a result, the JS function of sending an ajax request to our actions file is triggered, which in turn starts the standard function, the essence of which is to create a curl request to our API server updates, and get an answer : is there a new version and if there are any changes have occurred. Thereafter:

1. Download the archive of necessary files for updating.

2. A backup copy of all files and databases is made locally.

3. Delete all current files.

4. New files are unzipped and copied to the working directory.

5. Delete temporary files and archives.

6. Update is ready.

Of course, there are downsides to this approach. If you have your own configuration, then you do not have the ability to update, since the new version will delete the files of the old one. You can manually monitor and restore the necessary files, but this is not as convenient as we would like.

From the developer’s side, the project’s headliner pushes into the main repository, after which post-receive HOOK is triggered, which:

1. Creates the main distribution of the latest version of the product.

2. Creates an archive for the update system with only the files needed for updating.

Licensing issue

As soon as we realized that the system was moving into a paid channel, we thought about licensing. More precisely about the control of the distribution code. Since 90% of the code is PHP, ~ 8% is JS, ~ 2% is CSS, you could use Zend Guard or ioncube. But the cost of these products is quite high, as for our startup. In addition, we did not want customers and users to perplex with unnecessary actions to install the necessary software and then constant checks of the product. We trust our customers just as they trust us when they buy this product. Therefore, we do not have bindings by ip or domain names.

Parallel development

In parallel with our product, we are developing and in the near future we will release an IOS-application that will allow us to process applications with the minimum functional interface. The main focus was on receiving push-messages about new events regarding applications. To develop such an application, an API script was written that handles the main functions: authorization, retrieving the current list of applications, viewing the application, locking / unlocking, and executing / non-performing a specific application.



From here, we decided to further develop the API, while creating the basis for the development of mobile application functionality and the new API system object, for integration with various services and systems.

What are open problems and unresolved issues?

All support for current customers is still in manual mode, that is, it is skype / email. It is planned to create a platform that will create a community of users for the further development of the project. Perhaps there will be another product based on this.

Documentation for developers is also not yet available, which in turn complicates product development for new developers who have joined the team. The first is the API, the architecture of the project, the main functions and modules of the system.

Installing nodejs and its support requires manual installation of nodejs, socket.io, mysql. As well as forever - for continuous monitoring and support of the server. For some, these actions are problematic. We are working on writing an installation script that will facilitate this process. We also move from forever to PM2.

Approach to customers

Very often we caught ourselves thinking that we give more than we receive. Rather, it is so far. Because, as we are free or with large discounts, we distribute the product to educational institutions, we help to introduce them into new organizations' infrastructures, to advise on the possible nuances of work. Our task is not to make money on this product, which of course is a natural desire, but to gain experience in the development workflow, communication with customers and their remote support. We always offer a free remote installation, despite the fact that there is documentation and a simple installation script. Our product is not perfect, but we strive for this constantly, thanks to the feedback and comments. Similarly, the goal of this article is to obtain the maximum basis for the further development of the project.

Total

We very much hope that our product will take its place in the world of products to optimize and organize the workflow. In any case, for us this is another great experience. We will be glad to hear comments in the style: “it would be possible to do so ..”, “it would not be too bad to do ...”, “we have implemented it this way ...”. We will not give consulting answers, since the purpose of this article is not advertising and not an offer to buy our product, but to share the experience of the workflow, the creation of a new product.