{"id":902,"date":"2019-10-31T11:25:37","date_gmt":"2019-10-31T11:25:37","guid":{"rendered":"https:\/\/blog.lboro.ac.uk\/middleware\/?p=902"},"modified":"2019-10-31T11:31:15","modified_gmt":"2019-10-31T11:31:15","slug":"the-fast-and-the-furious-one-click-quick-tickets-for-rt","status":"publish","type":"post","link":"https:\/\/blog.lboro.ac.uk\/middleware\/blog\/rt\/the-fast-and-the-furious-one-click-quick-tickets-for-rt","title":{"rendered":"The Fast and the Furious: One click quick tickets for RT"},"content":{"rendered":"\n

\nJon and I have blogged before about some of\nthe ways we\u2019ve extended Best Practical\u2019s Request Tracker (RT) to\nadd functionality, but we\u2019ve not really talked about how we enhance\nwhat\u2019s already there. In this case we wanted to have a way to\nhandle high volume, repeat tickets. We\u2019re not that interested in\nwho has the problem, more how many times it\u2019s coming up, where it\u2019s\nbeing seen and when.<\/p>\n\n\n\n

Freshers week<\/strong><\/p>\n\n\n\n

\nThe annual Freshers Week (which tends to\nlast somewhat longer than a week) sees about 5,000 new students\narrive and some 10,000 returners. This leads to a spike in work\nrequests, mainly (but not exclusively) around getting devices\nconnected to our wireless network. In this case, we are pretty sure\nwe know what requests are going to arrive, but we want to be sure we\nare adequately setup to cope with the busiest periods. In order to\nmeasure demand, we need a system that is as quick as recording a pen\nstroke for a 5-bar gate. Alongside this we run kiosks for the\nstudents around the campus, these can be anything from a dedicated\ndesk, to a throw-up tent. A secondary requirement was to find out\nwhich of these kiosks, were the most popular and have them correctly\nstaffed to meet demand.<\/p>\n\n\n\n

To this end a quick ticket system was developed, from the systems already implemented within RT, which recorded a minimum amount of data in the shortest time possible.<\/p>\n\n\n\n

\"\"
Fig 1: Freshers Week Quick Ticket Portlet<\/figcaption><\/figure>\n\n\n\n

There are two parts to the ticket portlet. The first is capturing the kiosk number. As a stint at a kiosk was normally a few hours, we wanted to have our staff set their location once and have the portlet remember it for the duration of the session. This is achieved by a simple numerical dropdown html form field (as an RT Custom Field) and the use of browser localStorage, via javascript.<\/p>\n\n\n\n

<script>\n    jQuery(document).ready(function(){\n        jQuery('#kioskNumber').change(saveSettings);\n        loadSettings();\n    });\n    function loadSettings() {\n        jQuery('#kioskNumber').val(localStorage.Kiosk);\n        jQuery('input[name=\"Object-RT::Ticket--CustomField:Kiosk-2-Value\"]').val(jQuery('#kioskNumber').val());\n    }\n    function saveSettings() {\n        localStorage.Kiosk = jQuery('#kioskNumber').val();\n        jQuery('input[name=\"Object-RT::Ticket--CustomField:Kiosk-2-Value\"]').val(jQuery('#kioskNumber').val());\n    }\n<\/script><\/code><\/pre>\n\n\n\n
\nThe above javascript stores the kiosk\nchoice in the browsers storage and recalls it every time the page is\nreloaded.<\/p>\n\n\n\n
\nOnce we had a method of recording the kiosk\nnumber, we then needed a set of buttons to record the issues. These\nbuttons and the kiosk dropdown, feed into the form to create the\nticket.<\/p>\n\n\n\n
 The ticket data is formed of a prescribed subject, a status of resolved, who created the ticket and when it was done.<\/p>\n\n\n\n
% my $prefix = '[Freshers Week] ';\n% my @subjects = (\u2018My\u2019, \u2018array\u2019, \u2018of\u2019, \u2018subjects\u2019);\n% foreach my $thisSubject (@subjects) {\n<form\n    method=\"post\"\n    action=\"<%RT->Config->Get('WebPath')%><% $r->path_info %>\"\n% $m->callback(CallbackName => 'InFormElement');\n>\n<input type=\"hidden\" class=\"hidden\" name=\"QuickCreate\" value=\"1\" \/>\n<input type=\"hidden\" class=\"hidden\" name=\"Queue\" value=\"3\" \/>\n<input type=\"hidden\" class=\"hidden\" name=\"Subject\" value=\"<%$prefix%><%$thisSubject%>\"\/>\n<input type=\"hidden\" class=\"hidden\" name=\"Owner\" value=\"<%$session{'CurrentUser'}->id%>\" \/>\n<input type=\"hidden\" class=\"hidden\" name=\"Requestors\" value=\"<%$session{'CurrentUser'}->EmailAddress%>\" \/>\n<input type=\"hidden\" class=\"hidden\" name=\"Object-RT::Ticket--CustomField:Kiosk-2-Value-Magic\" value=\"1\" \/>\n<input type=\"hidden\" name=\"Object-RT::Ticket--CustomField:Kiosk-2-Value\" id=\"Object-RT::Ticket--CustomField:Kiosk-2-Value\" class=\"CF-2-Edit\" value=\"1\" \/>\n<input type=\"hidden\" class=\"hidden\" name=\"Status\" value=\"resolved\" \/>\n<& \/Elements\/Submit, Label => loc(\"$thisSubject\") &>\n<\/form><\/code><\/pre>\n\n\n\n
 The above code will create a ticket in queue 3, via the QuickCreate method, as used by RT\u2019s default quick ticket creator. Using this method, we are able to create tickets at the push of a button, the QuickCreate method does not take you to a new page, instead it simply acknowledges the creation of the ticket and refreshes the page the portlet is on, as seen below:<\/p>\n\n\n\n
\"\"
Fig 2: A ticket has been created and resolved. The interface acknowledges the ticket and the portlet is ready for the next case<\/figcaption><\/figure>\n\n\n\n
 We can now take the data that is created and report back on the busy periods at any of the kiosks (see figures 3 and 4), to allow us to plan ahead for the next academic year, in terms of how we staff our kiosks and where we place them.  <\/p>\n\n\n\n
\"\"
Fig 3: Mapping of the hourly demand at kiosk1, across the entirety of Freshers Week<\/figcaption><\/figure>\n\n\n\n
\"\"
Fig 4: The same search at kiosk2, showing a different demand pattern<\/figcaption><\/figure>\n\n\n\n
 Further we can use the same data these tickets are generating to see what the major requests are (via the prescribed subject line) and if necessary have more specialised staff on hand (or target training for our current staff) in future years, to help manage the demand. In order to achieve this a slight modification to the dropdown list on RT\u2019s chart form is needed, to add the option for \u201cSubject\u201d<\/p>\n\n\n\n
\"\"
Fig 5: Demand by subject at a kiosk, throughout Freshers Week<\/figcaption><\/figure>\n\n\n\n
 Day to Day on the PC Clinic<\/strong><\/p>\n\n\n\n
\nThese quick tickets proved so popular and\nuseful we were asked to extend them, to deal with regular requests\noutside of Freshers Week, during normal term time. As with the\nFreshers Week tickets, the requirement for single click 5 bar gate\nstyle recording was kept. In the case of the term time tickets its\nwas requested that we have a method for recording who has the issue. \n<\/p>\n\n\n\n
 In this case we modified another piece of existing RT code to create a new portlet, that has many of the similarities of the Freshers Week array, but also includes a user lookup (the thinking here is to try and find people who may be having recurring problems)<\/p>\n\n\n\n
<table>\n  <tbody>\n    <tr class=\"input-row\">\n    <td class=\"label\"><&|\/l&>Requestors<\/&>:<\/td>\n    <td colspan=\"3\" class=\"value\"><& \/Elements\/EmailInput, Name => 'Requestors', id => 'Requestors', Size => '40', Default => $args->{Requestors} || $session{CurrentUser}->EmailAddress, AutocompleteMultiple => 1 &><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table><\/code><\/pre>\n\n\n\n
 This addition along with a few minor teaks to the form code, to allow a different list of issues and to detect the requestor, allows us to continue using these quick tickets on our permanent PC Clinic, throughout the year.<\/p>\n\n\n\n
\"\"
Fig 6: The portlet for day to day Quick Tickets<\/figcaption><\/figure>\n\n\n\n
 This method of recording tickets has proven itself to be able to handle large amounts of cases at the busiest times of the year and is  providing our management with useful data, to enable future planning to make sure we provide our staff and students with an excellent user experience. It would appear that the RT service owner is certainly happy with them, based on the amount of chocolate biscuits we\u2019re receiving.<\/p>\n","protected":false},"excerpt":{"rendered":"
Jon and I have blogged before about some of the ways we\u2019ve extended Best Practical\u2019s Request Tracker (RT) to add functionality, but we\u2019ve not really talked about how we enhance what\u2019s already there. In this case we wanted to have … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[70],"tags":[],"class_list":["post-902","post","type-post","status-publish","format-standard","hentry","category-rt"],"_links":{"self":[{"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/posts\/902","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/comments?post=902"}],"version-history":[{"count":5,"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/posts\/902\/revisions"}],"predecessor-version":[{"id":915,"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/posts\/902\/revisions\/915"}],"wp:attachment":[{"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/media?parent=902"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/categories?post=902"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/tags?post=902"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}