How we wrote helpdesk
There are products that can be taken and used, but with a slight modification “for themselves”. So the application system or helpdesk just does not apply to such things. More precisely, we did not find a suitable product for ourselves and decided to make it ourselves.
Initially, we had initial ones from which we repelled and later demands were made:
')
The position of me as a developer was based on a segment of ready-made opensource products that support php & mysql. Initially, they considered: OsTicket , which is quite simple, but at the same time, much functional, which in turn is a minus (a lot of extra "cut and hide", and what needs to be added is). As well as a more serious solution - OTRS , which has a built-in tool to work with LDAP. He especially liked the application creation form, in which when entering the client ID all information about him was pulled up. And so I wanted a "golden mean." The general conclusion is that not one of them is suitable for specific requirements, but because of the interface, the latter can at least ignore part of the requirements. Having little experience in developing php / jquery projects, I decided to write my own system.
The main tasks were: accounting of all applications, reporting and control by the management, at what stage is one or another task. For example, the head of the department in the evening could determine the tasks for the next day for his subordinates, choosing a priority for them. And subordinates, having come to work, could immediately see the list of tasks and, for a certain time, carry them out.
As such, we did not have a clear technical assignment. Therefore, we have roughly determined the structure of the system and its modules.
As can be seen from the model, I also wanted to use the system of "personal messages" of users. But in the future this idea disappeared, but instead we decided to add:
A lot of time and work was devoted to the process of creating an application. As I wrote above, I liked the approach in OTRS. Therefore, in order for a customer to call, he could be identified by learning about his previous applications and the number of calls, it was necessary to fill the customer base. We have a part of customer information stored in Active Directory, the other part - in the telephone directory of the doc format. In AD there were only: name, login, email and group (division). In the doc directory were: full name, phone, office. Together they complemented each other. In these two sources, units of information could not be the same. For example, there were about 2000 entries in the LDAP, and 1200 entries in the directory. Of these, ~ 1000 coincided. Well, that was enough.
The process was defined in several stages:
As a result, we have a collection table with over 1000 records of information about the company's customers. When creating an application, we can enter the phone number, full name or login to find out information about the client, his number of requests and recent requests.
This is not the first project in which I chose such an organization of files. Perhaps this can be called a “design pattern”, correct if I am mistaken.
For me, such an organization of “communication” of files seemed more logical and simple. Everything is located where it belongs. The file actions.php mainly consists of action blocks, such as “create an application”, “block an application”, “add a client”, etc. A POST request with a specific name is sent to it, which calls the necessary part of the code. As for the description of events on the page, core.js is responsible for this.
About the motion of the application itself, it is worth to tell in more detail. As a rule, from the entire staff, 1-2 human operators or attendants, who receive applications: 80% over the telephone, 20% in place. We have always held the opinion that it is important to solve a problem before creating an application. And if this problem / task is not within the competence of the employee, then he directs it to the core department or a specific person. If the recipient of the application is selected by the department, then this application will be seen by everyone who is in this department (and of course the head of the department). If a particular person is selected, then this person and his boss will see such an application. The rest of the users of the department will not see the application.
The idea is that the application would not go unheeded and its status of execution could always be observed by the head of the department.
In the development process, it was decided to make a 3-tier system of user rights.
The bottom line is that the Chief Administrator sees applications from all departments and all users. The coordinator is in a certain department (s) and sees the requests of all users of this particular department (s). The user sees only those applications that are sent to his department (all) or specifically to him. Applications to other users from his department, he does not see.
After a while, we were faced with a collision: users physically entered one department, but in fact the work was adjacent to other departments. And they needed to see applications from other departments, but with different rights. Thus, the idea of a “vertical-horizontal” orientation of access rights was born. Vertically - these were user rights: admin / coordinator / user. And horizontally - this is a list of those departments in which he could enter with general rights. The logical point of intersection of these lines was the general access rights to the system.
When testing, we saw that it was not very noticeable when a new application appeared. For example, a person on one monitor may have the helpdesk open in the browser, but when a new application appears, he will not see anything. Not good. And then we decided to make pop-up messages in the popular social network. They work on different actions, like this:
For popup messages, on certain pages we send every 2 seconds an ajax request of 208 bytes, which asks the script on the server: “is there anything new for the user?” And if there is, the client receives a json response. Of course, for complete "beauty", this is done through sockets. But so far we have not come to this. Also added the flickering effect of the title-page and the title of the tab clearly shouted: “something has been updated here, pay attention”.
Most recently, we have implemented a jabber-messenger. Therefore, we immediately connected helpdesk to it and now notifications about new applications come to Jaber. Some employees are not in their workplaces, but work with clients (install software, service equipment). Therefore, special attention to them on the notification of new applications. The most optimal and easiest way is sms-notification. We found a convenient service and integrated its system through its API.
An important point was getting access to the application system, existing users of the IT-department. We created a login / email whitelist. Its essence was as follows: when a person logs in via the web, he clicks on the “first login” link, and enters only his ldap login. A letter with the created password and the link to which it passes and gets full access to the system comes to his domain mail. Thus, the task was removed from the system administrator to each issue accounts.
How convenient and justified was the writing of such a system, time will tell. In the meantime, we try not to turn it into a “monster”, but at the same time add some features: adding file uploads to the application, statistics and other things. My personal critical opinion is that the system is quite working, but it is still necessary to work with the code. I will be very pleased to hear your criticism and comments, as well as see your contribution to the development of the project.
Github: link .
Initially, we had initial ones from which we repelled and later demands were made:
- Slightly more than 2,000 users who will not participate in the application system, but whose call statistics should be recorded
- About 30 staff members who are divided into 3-4 departments, in which the head and they all have access to helpdesk
- The system is for internal corporate use only.
- Email / sms notification
- Reporting and statistics
- User base (ideally taken from ActiveDirectory, at least partially)
')
The position of me as a developer was based on a segment of ready-made opensource products that support php & mysql. Initially, they considered: OsTicket , which is quite simple, but at the same time, much functional, which in turn is a minus (a lot of extra "cut and hide", and what needs to be added is). As well as a more serious solution - OTRS , which has a built-in tool to work with LDAP. He especially liked the application creation form, in which when entering the client ID all information about him was pulled up. And so I wanted a "golden mean." The general conclusion is that not one of them is suitable for specific requirements, but because of the interface, the latter can at least ignore part of the requirements. Having little experience in developing php / jquery projects, I decided to write my own system.
The main tasks were: accounting of all applications, reporting and control by the management, at what stage is one or another task. For example, the head of the department in the evening could determine the tasks for the next day for his subordinates, choosing a priority for them. And subordinates, having come to work, could immediately see the list of tasks and, for a certain time, carry them out.
As such, we did not have a clear technical assignment. Therefore, we have roughly determined the structure of the system and its modules.
As can be seen from the model, I also wanted to use the system of "personal messages" of users. But in the future this idea disappeared, but instead we decided to add:
- Comments on the application page, in order to discuss the application or unsubscribe on its implementation
- Divide the applications into 3 categories: Incoming, Outgoing, Archive (in which applications are automatically entered after a certain time, with the status "completed")
- Knowledge Center (section in which you could find answers to your questions, solve the problem without creating an application. There may be instructions, manuals, documentation)
- Notepad (for storing personal notes and records, with the ability to share a link to them)
- Logging of all user actions
A lot of time and work was devoted to the process of creating an application. As I wrote above, I liked the approach in OTRS. Therefore, in order for a customer to call, he could be identified by learning about his previous applications and the number of calls, it was necessary to fill the customer base. We have a part of customer information stored in Active Directory, the other part - in the telephone directory of the doc format. In AD there were only: name, login, email and group (division). In the doc directory were: full name, phone, office. Together they complemented each other. In these two sources, units of information could not be the same. For example, there were about 2000 entries in the LDAP, and 1200 entries in the directory. Of these, ~ 1000 coincided. Well, that was enough.
Filling customer base
The process was defined in several stages:
- Import from AD was the path of PHP. Standardly connected to LDAP, pulling out the necessary information.
- Import from the doc-directory was much more interesting. First, the necessary table data was transferred to xls, formatted and saved to CSV.
- Next, the import into the MySQL-table did a php-script, which in a cycle went through LDAP-records and sql-records and compared the full name (this is the only thing they had in common).
As a result, we have a collection table with over 1000 records of information about the company's customers. When creating an application, we can enter the phone number, full name or login to find out information about the client, his number of requests and recent requests.
Coding
This is not the first project in which I chose such an organization of files. Perhaps this can be called a “design pattern”, correct if I am mistaken.
For me, such an organization of “communication” of files seemed more logical and simple. Everything is located where it belongs. The file actions.php mainly consists of action blocks, such as “create an application”, “block an application”, “add a client”, etc. A POST request with a specific name is sent to it, which calls the necessary part of the code. As for the description of events on the page, core.js is responsible for this.
Motion application
About the motion of the application itself, it is worth to tell in more detail. As a rule, from the entire staff, 1-2 human operators or attendants, who receive applications: 80% over the telephone, 20% in place. We have always held the opinion that it is important to solve a problem before creating an application. And if this problem / task is not within the competence of the employee, then he directs it to the core department or a specific person. If the recipient of the application is selected by the department, then this application will be seen by everyone who is in this department (and of course the head of the department). If a particular person is selected, then this person and his boss will see such an application. The rest of the users of the department will not see the application.
The idea is that the application would not go unheeded and its status of execution could always be observed by the head of the department.
In the development process, it was decided to make a 3-tier system of user rights.
The bottom line is that the Chief Administrator sees applications from all departments and all users. The coordinator is in a certain department (s) and sees the requests of all users of this particular department (s). The user sees only those applications that are sent to his department (all) or specifically to him. Applications to other users from his department, he does not see.
After a while, we were faced with a collision: users physically entered one department, but in fact the work was adjacent to other departments. And they needed to see applications from other departments, but with different rights. Thus, the idea of a “vertical-horizontal” orientation of access rights was born. Vertically - these were user rights: admin / coordinator / user. And horizontally - this is a list of those departments in which he could enter with general rights. The logical point of intersection of these lines was the general access rights to the system.
When testing, we saw that it was not very noticeable when a new application appeared. For example, a person on one monitor may have the helpdesk open in the browser, but when a new application appears, he will not see anything. Not good. And then we decided to make pop-up messages in the popular social network. They work on different actions, like this:
For popup messages, on certain pages we send every 2 seconds an ajax request of 208 bytes, which asks the script on the server: “is there anything new for the user?” And if there is, the client receives a json response. Of course, for complete "beauty", this is done through sockets. But so far we have not come to this. Also added the flickering effect of the title-page and the title of the tab clearly shouted: “something has been updated here, pay attention”.
Most recently, we have implemented a jabber-messenger. Therefore, we immediately connected helpdesk to it and now notifications about new applications come to Jaber. Some employees are not in their workplaces, but work with clients (install software, service equipment). Therefore, special attention to them on the notification of new applications. The most optimal and easiest way is sms-notification. We found a convenient service and integrated its system through its API.
Integration
An important point was getting access to the application system, existing users of the IT-department. We created a login / email whitelist. Its essence was as follows: when a person logs in via the web, he clicks on the “first login” link, and enters only his ldap login. A letter with the created password and the link to which it passes and gets full access to the system comes to his domain mail. Thus, the task was removed from the system administrator to each issue accounts.
What did we do?
- Multi-level user rights system
- JQuery-oriented interface structure
- The ability to register in the system from the "white list" e-mail addresses
- Notification of new applications by e-mail, sms, and other systems
- Custom settings
- Language support: Ukrainian, Russian, English
- Event message popups with requests (as in VK)
- Knowledge Center - a section for documentation files, instructions and help files with a rights structure
- Notepad - a user's personal notepad with the ability to share a link.
- Application statistics
- “Smart” creation of applications by number, full name, customer login
- Priorities of applications
- Comments and chat in the application
- Full logging of all actions by all users of the application
- And other...
Conclusion
How convenient and justified was the writing of such a system, time will tell. In the meantime, we try not to turn it into a “monster”, but at the same time add some features: adding file uploads to the application, statistics and other things. My personal critical opinion is that the system is quite working, but it is still necessary to work with the code. I will be very pleased to hear your criticism and comments, as well as see your contribution to the development of the project.
Github: link .
Source: https://habr.com/ru/post/227277/
All Articles