June 25, 2014 at 16:58As we wrote helpdesk
There are products that you can take and use, 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 the initial ones from which the requirements were repelled and later put forward:
My position as a developer was based on the segment of ready-to-use opensource products supporting php & mysql. Initially, they were considered: OsTicket , which is quite simple, but at the same time a lot of functional, which in turn is a minus (there is a lot of “cut and hide” too much, and what needs to be added). And also a more serious solution - OTRS, which has a built-in tool for working 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 "middle ground." The general conclusion is that not one of them is suitable for specific requirements, but the latter, due to the interface, can at least ignore some of the requirements. Having little experience developing php / jquery projects, I decided to write my own system.
The main tasks were: accounting for all applications, reporting and control by the management, at what stage this or that task is. For example, from the evening the head of the department 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 fulfill them within a certain time.
As such, we did not have a clear technical task. Therefore, we 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 venture 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, so that when a client calls, you can identify him, having learned about his previous applications and the number of calls, it was necessary to fill the customer base. At us, part of the customer information was stored in Active Directory, the other part was in the telephone directory of the doc format. In AD there were only: name, login, email and group (unit). In the doc directory were: name, tel, office. Together they complemented each other. In these two sources, the units of information may not coincide. For example, there were about 2,000 entries in LDAP, and 1,200 in the directory. Of these, ~ 1,000 were matched. Well, that was enough.
The process was determined in several stages:
As a result, we have a collection table with more than 1000 records of information about the company's customers. When creating an application, we can enter a phone number, full name or login in order to find out information about the client, his number of calls and recent applications.
This is not the first project in which I have chosen such file organization. Perhaps this can be called a "design pattern", correct if I am mistaken.
For me, such an organization of “communication” files seemed more logical and simple. Everything is located where it belongs. The actions.php file mainly consists of action blocks, such as “create a request”, “block a request”, “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 .
The movement of the application itself should be described in more detail. As a rule, there are 1-2 people who are the operator or attendants from all personnel who accept applications: 80% by telephone, 20% on the spot. We have always been of the opinion that it is important to solve the problem even before the creation of the application. And if this problem / task is not in the competence of the employee, then he sends it to the relevant department or to a specific person. If the recipient of the application has selected a department, then everyone who is part of this department (and of course the head of the department) will see such an application. If a specific person is selected, then this person and his boss will see such an application. The application will not be visible to other users of the department.
The idea is that the application would not be left unattended and its execution status could always be observed by the department head.
In the development process, it was decided to create a 3-tier system of user rights.
The bottom line is that the main Administrator sees the applications of all departments and all users. The coordinator is in a specific department (s) and sees the applications of all users of this particular department (s). The user sees only those applications that are sent to his department (to everyone) or specifically to him. He does not see applications to other users from his department.
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. This is how the idea of “vertical-horizontal” orientation of access rights was born. Vertical - these were user rights: admin / coordinator / user. And horizontally - this is a list of those departments into 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 can have a helpdesk opened in a browser, but when a new application appears, he will not see anything. Not good. And then we decided to make pop-up messages in a popular social network. They work according to different actions, like this:
For pop-up messages to work, on certain pages we send every 2 seconds an ajax request of 208 bytes, which asks the script on the server: “is there something new for the user?” And if there is, then 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. They also added the effect of flickering 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 of new applications come to jaber. Some employees are not at their workplaces, but work with clients (install software, service equipment). Therefore, they pay special attention to the notification of new applications. The most optimal and easiest way is an SMS notification. We found a convenient service and integrated our system through its API.
An important point was gaining access to the application system, existing users of the IT department. We have created a login / email whitelist. Its essence was as follows: a person who logs in via the web clicks on the "first login" link and enters only his ldap login. A letter with the created password and a link to which he goes 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 it was to write 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 you still need to work with the code. I will be very pleased to hear your criticism and comments, as well as to see your contribution to the development of the project.
Github: link .
Initially, we had the initial ones from which the requirements were repelled and later put forward:
- A little more than 2000 users who will not participate in the application system, but whose circulation statistics need to be recorded
- About 30 staff members are divided into 3-4 departments, in which the boss and all of them have access to the help desk
- System for internal corporate use only
- Email / sms notification
- Reporting and statistics
- User base (ideal with ActiveDirectory, at least partially)
My position as a developer was based on the segment of ready-to-use opensource products supporting php & mysql. Initially, they were considered: OsTicket , which is quite simple, but at the same time a lot of functional, which in turn is a minus (there is a lot of “cut and hide” too much, and what needs to be added). And also a more serious solution - OTRS, which has a built-in tool for working 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 "middle ground." The general conclusion is that not one of them is suitable for specific requirements, but the latter, due to the interface, can at least ignore some of the requirements. Having little experience developing php / jquery projects, I decided to write my own system.
The main tasks were: accounting for all applications, reporting and control by the management, at what stage this or that task is. For example, from the evening the head of the department 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 fulfill them within a certain time.
As such, we did not have a clear technical task. Therefore, we 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 venture disappeared, but instead we decided to add:
- Comments on the application page, in order to be able to discuss the application or unsubscribe on its implementation
- Divide applications into 3 categories: Inbox, Outbox, Archive (in which applications automatically fall after some time, with the status of "completed")
- Knowledge Center (a section in which one could find answers to questions of interest, solve a problem without creating an application. There may be instructions, manuals, documentation)
- Notepad (for storing personal notes and notes, with the ability to share a link to them)
- Logging 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, so that when a client calls, you can identify him, having learned about his previous applications and the number of calls, it was necessary to fill the customer base. At us, part of the customer information was stored in Active Directory, the other part was in the telephone directory of the doc format. In AD there were only: name, login, email and group (unit). In the doc directory were: name, tel, office. Together they complemented each other. In these two sources, the units of information may not coincide. For example, there were about 2,000 entries in LDAP, and 1,200 in the directory. Of these, ~ 1,000 were matched. Well, that was enough.
Filling customer base
The process was determined in several stages:
- Importing from AD was through PHP. Standardly connected to LDAP, pulling the necessary information.
- Import from the doc-directory was much more interesting. First, we transferred the necessary table data to xls, formatted and saved it in CSV.
- Next, import into the MySQL table was done by a php script, which looped through LDAP records and sql records and compared the name (this is the only thing they had in common).
As a result, we have a collection table with more than 1000 records of information about the company's customers. When creating an application, we can enter a phone number, full name or login in order to find out information about the client, his number of calls and recent applications.
Coding
This is not the first project in which I have chosen such file organization. Perhaps this can be called a "design pattern", correct if I am mistaken.
For me, such an organization of “communication” files seemed more logical and simple. Everything is located where it belongs. The actions.php file mainly consists of action blocks, such as “create a request”, “block a request”, “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 .
Application movement
The movement of the application itself should be described in more detail. As a rule, there are 1-2 people who are the operator or attendants from all personnel who accept applications: 80% by telephone, 20% on the spot. We have always been of the opinion that it is important to solve the problem even before the creation of the application. And if this problem / task is not in the competence of the employee, then he sends it to the relevant department or to a specific person. If the recipient of the application has selected a department, then everyone who is part of this department (and of course the head of the department) will see such an application. If a specific person is selected, then this person and his boss will see such an application. The application will not be visible to other users of the department.
The idea is that the application would not be left unattended and its execution status could always be observed by the department head.
In the development process, it was decided to create a 3-tier system of user rights.
The bottom line is that the main Administrator sees the applications of all departments and all users. The coordinator is in a specific department (s) and sees the applications of all users of this particular department (s). The user sees only those applications that are sent to his department (to everyone) or specifically to him. He does not see applications to other users from his department.
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. This is how the idea of “vertical-horizontal” orientation of access rights was born. Vertical - these were user rights: admin / coordinator / user. And horizontally - this is a list of those departments into 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 can have a helpdesk opened in a browser, but when a new application appears, he will not see anything. Not good. And then we decided to make pop-up messages in a popular social network. They work according to different actions, like this:
For pop-up messages to work, on certain pages we send every 2 seconds an ajax request of 208 bytes, which asks the script on the server: “is there something new for the user?” And if there is, then 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. They also added the effect of flickering 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 of new applications come to jaber. Some employees are not at their workplaces, but work with clients (install software, service equipment). Therefore, they pay special attention to the notification of new applications. The most optimal and easiest way is an SMS notification. We found a convenient service and integrated our system through its API.
Integration
An important point was gaining access to the application system, existing users of the IT department. We have created a login / email whitelist. Its essence was as follows: a person who logs in via the web clicks on the "first login" link and enters only his ldap login. A letter with the created password and a link to which he goes 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 happened to us?
- Multilevel user rights system
- JQuery-oriented interface structure
- The ability to register in the system from the "white list" of e-mail addresses
- Notification of new applications by e-mail, sms, and other systems
- User settings
- Language Support: Ukrainian, Russian, English
- Application event pop-up messages (as in VK)
- Knowledge Center - a section for documentation files, instructions and help files with a rights structure
- Notepad - a user's personal notebook with the ability to share a link
- Application Statistics
- “Smart” creation of applications by number, name, client login
- Application Priorities
- Comments and chat in the application
- Full logging of all actions by all users of the application
- And other...
Conclusion
How convenient and justified it was to write 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 you still need to work with the code. I will be very pleased to hear your criticism and comments, as well as to see your contribution to the development of the project.
Github: link .