As we wrote helpdesk (part 2)

In the continuation of part 1 , we decided to write an article on how we reached a “new level” in creating a web product. I want to immediately clarify that this is not quite a helpdesk, which is based on the creation of applications by clients (although this possibility is present), but is more designed for 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 no worse. It is simply “different”, which has its own functions for specific tasks and will probably take its rightful place in the general world of products that make the IT world better.

Foreword

After the release of the article on 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 influenced positively.
1. We found out what functions people want and then some (necessary in our opinion) were used at home.
2. Found bugs and fixed them.
3. A list of necessities appeared, which became the “development route” - ROADMAP.

The issue of organizing the workflow became acute. I realized that it’s difficult to code, communicate on development issues and check / test the bugs found. The project was developing more and more and at some point the idea came that our contribution to the project exceeded our expectations. We decided to receive a symbolic reward.

Criticism

There was a lot of criticism that they abandoned the project and offer only a paid version. But we always made a compromise - get in line, help, be part of our team, make a contribution and get rewards for this. If there is no opportunity to buy a product, we ask: how can you help the development of the project? And then there was 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 is these words, as the basis, that made us write our system, and not take a ready-made or paid one.
In order to understand how the system is nevertheless applied, it is best to give a life example when there is a boss who has several subordinates. These people work on the principle - do the task or pass it on to another. That would control the execution of tasks and is precisely such a system.
This is good because:
1. The result of work and the workload of each employee is visible
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 application of our system has already been found in government bodies, it-departments, agro-industrial enterprises, technical support services, delivery and other areas. By its purpose, the system focuses specifically 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 something like this: we are an IT department, working with tasks that are created by a head or coordinator. These tasks can also be created by users of the system themselves, receiving them from customers by phone. Clients themselves can also create applications from their personal account.

What's 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 actions on the user’s page and processing of a particular UI element)
- Actions php file (taking actions from ajax requests and processing them, a kind of API part)
- Functions and classes (based on which actions and other system files work)
It was such a structural approach to the organization of the project that was invented by me. Using NodeJS, a web socket layer has been added that constantly checks the event queue. Several scripts that run on schedule and are responsible for the notification queue and transferring applications to the archive. The version update system allows you to update the entire system in one click, while creating a backup of the current system. Details of the entire system description below.

What exactly made us switch to paid development?

The structure of clients / users
Previously (in the opensource version), the system had two logically different entities and tables. On the one hand, it was convenient in that full-fledged users of the system were in one place, and customers without access and rights were in another. But in the new version, we organized the possibility of access to the system for ordinary customers, to create applications. Thus, the system allows you to separately implement the personal account templates of your own CRM system in ours and integrate the two products.
Any user can be connected to LDAP, and assign him certain rights. Quite often, we transfer new thousands of accounts to zenlix to new clients with an already existing Active Directory, so that clients can create requests using their AD-login / password.

NodeJS and notifications- Earlier, users received pop-up notifications thanks 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 themselves from the server with the necessary commands and process them on the client side. This is how the system of pop-up messages for events works:
- a new application,
- a commented application,
- a blocked / unlocked application,
- a completed / failed application,
- a chat message.
This significantly reduced the load on the server.

Notification system
This is not only email notifications, but also using third-party services such as pushbullet, sms, jabber and others. We have moved from the procedural execution of sending emails on user actions to the logically planned one. Notifications should be understood as sending letters and launching the functions of libraries of third-party services. As a result, after each completed action with the application, which led to the sending of notifications, the user waited for notifications (letters, pushbullet) and others to be sent to all participants (and if there are about 20 of them!), Then creating an application for the department (sending a notification ) took so much time that the script gave timeout.
Today, we already have a system in place that processes a huge number of notifications in a short period of time, has a check on the completion of sending notifications. This works thanks to the queue system. All events are accumulated in the database table, which is checked at intervals once a minute, using a script that sends all notifications for all services. Thus, sending notifications works asynchronously from user actions with the UI.

The template was selected from the AdminLTE series and as the description says: “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 fairly nice set of UI elements that are pleasing to the eye people constantly working with the system.

Task Manager
This is something that I did not want to do so, but we were forced to because of a persistent client. Thanks to this functionality, we are able to create an application with certain parameters and plan its creation with the frequency we need. This applies to typical regulated tasks such as servicing equipment or creating backups.

Reports and graphs
We were so often asked to write and display reports according to certain criteria that we simply combined the most frequent requests into several informative reports. Now we can look at statistics
- for specific users for a certain period,
- for selected departments for a period,
- general statistics of the entire department.
At the same time, personal statistics are available to each user of the system.

Update system The
user clicks on the button in the admin menu, as a result of which 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 form a curl request to our update API server, and get an answer: is there a new version and if so what changes have occurred. After that:
1. Download the archive of the necessary files for updating.
2. A local backup of all files and databases is made.
3. All current files are deleted.
4. New files are unzipped and copied to the working directory.
5. Temporary files and archives are deleted.
6. Update is ready.
Of course there are conssuch an approach. If you have your own configuration, then you have no way to update, since the new version will delete the files of the previous one. You can manually monitor and restore the necessary files, but this is not as convenient as we would like.
From the developers' side, the project headliner makes a push to the main repository, after which the 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 only with the files necessary 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 control over the distribution of 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 to puzzle customers and users with unnecessary steps to install the necessary software and then constantly check the product. We trust our customers the same way they trust us in purchasing this product. Therefore, we do not have bindings by ip or domain names.

Parallel development

In our product, we are simultaneously developing and in the near future we will release an iOS application that will allow applications to be processed as conveniently as possible with a minimal functional interface. The main emphasis was on receiving push messages about new events regarding applications. To develop such an application, an API script was written that processes the main functions: authorization, receiving the current list of applications, viewing the application, blocking / unblocking, and executing / not fulfilling a specific application.

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

What are the open problems and unresolved issues?

All support for current customers is still in manual mode, that 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 the development of the product for new developers who have joined the team. The first is the API, the architecture of the project, the basic functions and modules of the system.
Nodejs installationand its support requires manual installation of nodejs, socket.io, mysql. As well as forever - for constant monitoring and server support. For some, these actions are problematic. We are working on writing an installation script that will facilitate this process. We are also moving from forever to PM2.

Customer approach

Very often we find ourselves thinking that we give more than we receive. Rather, it still is. Therefore, as we distribute the product for free to educational institutions, free of charge or at great discounts, we help introduce organizations into new infrastructures, and advise on possible nuances of work. Our task is not to capitalize on this product, which of course is a natural desire, but to gain experience in the development process, communicating with customers and their remote support. We always offer 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 reviews and comments. The goal of this article is to get the maximum base for further development of the project.

Total

We really hope that our product will take its place in the world of products to optimize and organize the workflow. In any case, for us it is another wonderful experience. We will be glad to hear comments in the style: “it would be possible to do so ..”, “it would not be bad to do it yet ...”, “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 work process, creating a new product.