Using Drupal for an IT Support Ticketing System
Issue tracking has the potential to make or break an IT team regardless of how well they perform. A ticketing solution must display information in such a manor to enable a user to obtain a solid grasp of the overall situation at a glance, and user/task specific details just a click away. The adaptability of Drupal makes it a stable platform to build on.
Table of Content
- Support Ticketing System Requirements
- User Roles and Content Permissions
- Creating Custom Content Types
- Drupal Modules
The purpose of this post is to provide a concept base to build on, the decision was made not to include an installation profile to allow you to decide what features, modules and fields best fit the needs of your support team. An understanding of Drupal will help out, so if you are not familiar with this CMS system spend some time reading the community documentation.
These requirements are just a guide to creating your own list, the nature of support requests differs in every organization as do requirements of notifications and user interfaces, taking the time to document necessary fundamentals will save time in development through maintenance.
- - Easy submissions of support requests
- - Different types of requests to allow distinction between help desk, change management, and other tickets
- - Notification to a central mailbox when a ticket is created
- - Ability to subscribe to updates per ticket, content type, or author depending on user role
- - Assign tickets to users and assigned notify user of the update
- - Comments, notes, status visible to ticket creator, managers, and IT personnel
- - Internal notes only visible to IT personnel
The extent of work require building user roles and content permissions depends heavily on the organization and actual use of your ticketing system. Help Desk, IT admin, Customer, and Web Admin should be the minimum for user roles created to manage users.
- Customers should only be able to view tickets they have created with permission to see the original request, updates or comments about the request, the status, who the ticket has been assigned to
- ♦ Ensure the Internal note checkbox is not checked for the customers user role
*CCK Content must be installed and enabled to create new content types.
The following fields were used for the support ticket content type and a quick run through of the fields purpose/setup...
- - Summary (instead of title)
- Assigned To (User Reference CCK field)
- ♦ This simple field adds significant functionality to the content type such as displaying tickets assigned to users on their user page, allows notifications to be sent via token actions, and the obvious ensuring there is a liable party to tackle the issue
- - Due Date (Datetime CCK field)
- Completed (Text checkbox CCK field requiring the options widget to be enabled in CCK)
- ♦ Issue tracking requires more than keeping a list open issues, it involves being able to go back to view notes about closed tickets, know how many times the issue has happened in the past, and have a record of who closed tickets to get the point of view they can offer if the issue resurfaces. It's common for departments to keep great records of current work and simply delete the entry once the work is complete, later on having to backtrack over hundreds of machines to find out what work was done and when. Instead of deleting tickets when they are completed, use the checkbox and create a view of closed tickets with a search option to encourage good record keeping by showing what it can achieve
- - Details (instead of Body)
- - Priority (radio button CCK text field, also requires options widget enabled)
- Internal Note (Text multiple line CCK field)
- ♦ Customers don't need to and should not be able to view all the information documented during support items. An internal note is meant for IT personnel only and can be made so using CCK content permissions.