{"id":859,"date":"2019-05-03T08:24:28","date_gmt":"2019-05-03T07:24:28","guid":{"rendered":"https:\/\/blog.lboro.ac.uk\/middleware\/?p=859"},"modified":"2019-05-15T08:19:45","modified_gmt":"2019-05-15T07:19:45","slug":"implementing-request-management-in-rt-quest-for-the-shopping-cart-part-1","status":"publish","type":"post","link":"https:\/\/blog.lboro.ac.uk\/middleware\/blog\/rt\/implementing-request-management-in-rt-quest-for-the-shopping-cart-part-1","title":{"rendered":"Implementing request management in RT: Quest for the shopping cart, part 1"},"content":{"rendered":"\n<p>We returned to <a href=\"https:\/\/bestpractical.com\">Best Practical\u2019s Request Tracker<\/a> (RT) as our service management tool, last year, with a remit to provide 3 processes which, when combined, would give us a workable service management system and allow our processes to expand and mature: <\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Incident Management \u2013 raise a ticket to handle an issue and have it dealt with, which is pretty much RT OOTB. <\/li><li>Change Management \u2013 controlling and standardising changes in the organisation (As recently blogged about by Jon <a href=\"https:\/\/blog.lboro.ac.uk\/middleware\/blog\/office365\/implementing-change-management-in-rt\">here<\/a>). <\/li><li>Request Management. <\/li><\/ul>\n\n\n\n<p>I\u2019m defining Request Management in the following manner:<\/p>\n\n\n\n<p><em>A Request is a repeatable, standardised method for acquiring something, that produces information in a known structured format that can be acted upon and which can have restricted access.<\/em><\/p>\n\n\n\n<p>With this definition in mind, and assuming that different\nrequests will have differing requirements (in terms of data captured and who\ncan make the request) we will need to look for something that:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>For requestors, is easy to find, accessible and\ncan glean the information required from them without causing confusion.<\/li><li>For the teams acting on these requests, the data\nis complete and presented in the team queue within RT in a standard manner.<\/li><li>The ability to have some requests available\ninside RT and some outside of the system, yet still going into the system.<\/li><\/ul>\n\n\n\n<p>This post details the Loughborough IT Services Request methodology, provides a broad overview of how we went about implementing this in RT, shows off RT&#8217;s flexibility and looks at the directions we may be heading in the future<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Implementing Requests at Loughborough<\/strong><\/h2>\n\n\n\n<p>Our initial requirements were to produce\na method to request two things: <\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Virtual Servers \u2013 built on the <a href=\"https:\/\/www.vmware.com\/\">VMWare<\/a> virtualisation platform, which can run a number of different operating systems and services. Some of these requests may require different hardware setups from the norm (more RAM, CPUs, storage etc), some could be windows servers which may, or may not then require SQL server or IIS Server or they could be Linux servers with IT Services standard build or built from a users ISO. Some may be for research by an individual, some may run university wide services. All of these options would need to be catered for. This request would go to our Infrastructure team queue.<\/li><li>TLS\/SSL certificates, which is simply a case of getting a certificate signing request (CSR) and, if the domain name the certificate is for is not local to Loughborough University (i.e. not a lboro.ac.uk domain), a University charge code. This request would go to our Security team queue.<\/li><\/ul>\n\n\n\n<p>Both of these requests needed to be\nlimited to being available to members of the RT Group \u201cIT Services\u201d<\/p>\n\n\n\n<p>These two initial requests are polar\nopposites in the information they need, the TLS request requires, at most,\nthree pieces of information whereas the Virtual Server request requires much\nmore and has many bits of information that are dependent on other bits. <\/p>\n\n\n\n<p>In order to collect this information we will need to modify the Create.html page where tickets are initially produced. We would normally do this via RT\u2019s built in Custom Fields. However as all of the requests we will need to cater for are unique (and hence would need some of their own Custom Fields, which would lead to an ever expanding custom field list and tickets that are very hard to read) and have to go to specific queues and potentially move around other queues, Custom Fields would become unwieldy as they would have to exist for all tickets in a team queue. Should the ticket ever need to be moved to another queue, the custom field data could be obscured, unless that queue also has that Custom Field. We therefore decided a number of things<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li>We would create our\nown bespoke web forms inside RT based on Create.html<\/li><li>We would use RT\u2019s\nMenu system and RT\u2019s Group system to restrict who can access the forms<\/li><li>All data gathered\nby these forms would be processed and collated as the initial ticket content<\/li><\/ol>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>TLS\/SSL Requests<\/strong><\/h2>\n\n\n\n<p>Starting with the simpler of the two\nforms, we created a copy of Create.html in [path\/to\/RT]\/RT4\/local\/html\/Ticket\/ called CreateSSLRequest.html.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"790\" height=\"556\" src=\"https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-04-30-at-12.56.01.png\" alt=\"\" class=\"wp-image-860\" srcset=\"https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-04-30-at-12.56.01.png 790w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-04-30-at-12.56.01-300x211.png 300w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-04-30-at-12.56.01-768x541.png 768w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-04-30-at-12.56.01-426x300.png 426w\" sizes=\"auto, (max-width: 790px) 100vw, 790px\" \/><figcaption>Figure 1: The TLS\/SSL certificate request form.<\/figcaption><\/figure>\n\n\n\n<p>The TLS\/SSL request form is very simple.\nThe only requirements we have are the CSR file which can be attached, as you would\nfor a standard RT ticket and a charge code if you are not requesting the\ncertificate for server with the university domain name. Figure 2 below shows\nhow the form reacts if you change the \u201cYes\u201d to a \u201cNo\u201d. This is controlled by a\nsimple piece of jQuery and CSS, slipped into the new CreateSSLRequest.html page\nand called as an onChange event.<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">function showChargeCode () {<br> \u00a0  if(jQuery('select[name=\\'Domain\\']').val() == 'Yes') {<br> \u00a0\u00a0\u00a0\u00a0   jQuery('tr.chargeCode').css('display', 'none'); <br> \u00a0  } else {<br> \u00a0\u00a0\u00a0\u00a0   jQuery('tr.chargeCode').css('display', 'table-row');<br> \u00a0  }<br>} <\/pre>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"726\" height=\"283\" src=\"https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-04-30-at-12.56.17.png\" alt=\"\" class=\"wp-image-861\" srcset=\"https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-04-30-at-12.56.17.png 726w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-04-30-at-12.56.17-300x117.png 300w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-04-30-at-12.56.17-500x195.png 500w\" sizes=\"auto, (max-width: 726px) 100vw, 726px\" \/><figcaption>Figure 2: The form reacts to ask for additional information for this request.<\/figcaption><\/figure>\n\n\n\n<p>Once the form is complete it can be\nsubmitted, where it is validated via javascript. This is fired from an onSubmit event\n(which submits to itself) collects the data and performs some simple tests to\ncheck there is something there. At this point you can add in as much validation\nas you need.<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">var domain = jQuery('select[name=\\'Domain\\']').val();<br>var chargeCode = jQuery('input[name=\\'chargeCode\\']').val();<br><br>if(domain == 'No' &amp;&amp; chargeCode == '') {<br>    alert(\"You must supply a charge code when acquiring a certificate for \" +  <br>\"a non lboro.ac.uk domain\");<br><br>    return false;<br>}<\/pre>\n\n\n\n<p>Assuming all is well, the form can have\nall of its data bundled up and submitted as the RT ticket content, like this:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">if(everythingIsOK) {<br>    jQuery('input[name=\\'Content\\']').val('Some text etc etc ' + domain + chargeCode );<br><br>    return true;<br>}<\/pre>\n\n\n\n<p>This\nsubmits the information with the attached CSR as a standard RT ticket into our Security\nQueue, where it can be worked on as normal.<\/p>\n\n\n\n<p>The above TLS\/SSL certificate request\nform is very simplistic, but should show how forms can be built inside RT\nwithout using the Custom Fields.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Virtual Server Request Form<\/strong><\/h2>\n\n\n\n<p>The Virtual Server Request form is a different beast entirely, although as with the TLS\/SSL form it starts off with a simple question, in order to check the requestor has performed the due diligence necessary before the request. In this case the first question is along the lines of \u201cDo you have a way to support this server\u201d (see Figure 3) <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"408\" src=\"https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-05-02-at-15.08.46-1024x408.png\" alt=\"\" class=\"wp-image-868\" srcset=\"https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-05-02-at-15.08.46-1024x408.png 1024w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-05-02-at-15.08.46-300x119.png 300w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-05-02-at-15.08.46-768x306.png 768w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-05-02-at-15.08.46-500x199.png 500w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-05-02-at-15.08.46.png 1170w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><figcaption>Figure 3: The initial view of the Virtual Server Request Form. As we are building standard html\/jquery forms, we can add lots of things. This one has a tool tip on the element, identified by the orange circle with the \u201ci\u201d inside.<\/figcaption><\/figure>\n\n\n\n<p>By selecting \u201cYes\u201d, as with the previous\nform, new elements are now exposed to the requestor (see Figure 4).<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"954\" height=\"970\" src=\"https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-04-30-at-13.45.24.png\" alt=\"\" class=\"wp-image-863\" srcset=\"https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-04-30-at-13.45.24.png 954w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-04-30-at-13.45.24-295x300.png 295w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/Screenshot-2019-04-30-at-13.45.24-768x781.png 768w\" sizes=\"auto, (max-width: 954px) 100vw, 954px\" \/><figcaption>Figure 4: The extended form, offering input and select boxes to control information.<\/figcaption><\/figure>\n\n\n\n<p>The extended form contains various elements along with tool tips to guide the user. The operating system box makes use of RT\u2019s Groups to decide what server options you can see. This is controlled by a mixture of Perl and html.<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">% my $groups = RT::Groups-&gt;new($session{'CurrentUser'});<br>% $groups-&gt;WithCurrentUser();<br>% $groups-&gt;LimitToUserDefinedGroups();<br>% while (my $group = $groups-&gt;Next()) {<br>%&nbsp;&nbsp; if($group-&gt;Name eq 'Group A') {<br>%&nbsp;&nbsp;&nbsp;&nbsp; $groupA = 1;<br>%&nbsp;&nbsp; } elsif($group-&gt;Name eq 'Group B') {<br>%&nbsp;&nbsp;&nbsp;&nbsp; $groupB = 1;<br>%&nbsp;&nbsp; }<br>% }<br>%<br>% if($groupA) {<br>&lt;option&gt;Networks CentOS 7 template (Managed by requestor)&lt;\/option&gt;<br>% }<br><\/pre>\n\n\n\n<p>Once a server option is selected,\nas with the previous form, additional fields can be exposed to gather more\nspecific data.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"939\" height=\"247\" src=\"https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/fig6.png\" alt=\"\" class=\"wp-image-864\" srcset=\"https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/fig6.png 939w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/fig6-300x79.png 300w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/fig6-768x202.png 768w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/fig6-500x132.png 500w\" sizes=\"auto, (max-width: 939px) 100vw, 939px\" \/><figcaption>Figure 6: By requesting Windows Server 2016, the requestor is now presented with options for IIS and SQL Server.<\/figcaption><\/figure>\n\n\n\n<p>This ability to hide and show\nfields in the form is controlled in the same way as the simpler TLS\/SSL form\nand the data gathered is validated, dependencies are checked and the\ninformation is collated in the same way and sent to RT as a ticket. The content\nof the Virtual Server Request form arrives in RT and appears as the first\ncontent entry in a structured format. This method can be expanded to forms that\ndon\u2019t exist within RT and they can collate the information into an initial\nemail, which can be posted into the system (of course these wont have the\nability to use extra data like RT Groups). The initial information for a\nVirtual Server ends up in RT like the below:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">VM Server Request<br> <br> Has support contract: Yes<br> Licencing understood: Yes<br> Business case: Internal<br> Business case justification: I really really need it<br> Proposed server name: Foo<br> Replaces existing server?: Yes<br> Name of existing server being replaced: Bar<br> Server description: FooBar Application Server<br> Development or Production?: Production<br> Application services supported: FooBar reporting<br> Server manager username: dave<br> Other server contacts: jon,katy<br> Operating System: Windows Server 2016 (IT Services managed)<br> IIS Required: No<\/pre>\n\n\n\n<p>A future enhancement to this\nform, will be to use a Custom Field to hold the same data in the ticket in JSON\nformat. This will allow us to access the data in a usable structure via RT\u2019s REST\nAPIs, to aid in the automation of server builds.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Accessing the Request forms<\/strong><\/h2>\n\n\n\n<p>Forms setup in the above manner\nand placed where they are, are accessible to anyone who is a privileged user in\nRT. RT is built in such a way that menu options are available to privileged or\nunprivileged users or both. This is helpful to us as we can control access to\nwhich type of user has access to which sort of request. However, we wanted to\ngo a stage further and restrict access to some of the forms, dependent on RT\nGroups. <\/p>\n\n\n\n<p>We have many groups of users on RT that are privileged (IT Services folk, Printing folk, Financial Services folk etc etc). Only members of the IT Services Group should be able to see the two requests we have created, as we want to make sure we have continuity of support for any server we deploy. For this we can use exactly the same trick that we used on the Virtual Server Request Form to offer restricted access to different server options and present requests on a Group basis. <\/p>\n\n\n\n<p>Two further requirements were the option to categorise our Requests and present them in a way that was easy to find and to display them more graphically, rather than in a nested menu structure. To this end, our scaling up plan will combine the usual drop down menus with RT, breaking requests into the various services they are for (e.g. IT Services requests, Printing requests, Library requests etc) and once this level is chosen, the&nbsp; various requests that can be accessed, are displayed in a tabular format, as seen in Figure 7.&nbsp; <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"939\" height=\"410\" src=\"https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/fig7.png\" alt=\"\" class=\"wp-image-865\" srcset=\"https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/fig7.png 939w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/fig7-300x131.png 300w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/fig7-768x335.png 768w, https:\/\/blog.lboro.ac.uk\/middleware\/wp-content\/uploads\/sites\/2\/2019\/05\/fig7-500x218.png 500w\" sizes=\"auto, (max-width: 939px) 100vw, 939px\" \/><figcaption>Figure 7: Various request choices displayed within RT.<a href=\"https:\/\/dryicons.com\/icon-packs\/coquette-icons-set\"> Icon by Dryicons <\/a><\/figcaption><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Hang on, didn\u2019t you say something about shopping carts??<\/strong><\/h2>\n\n\n\n<p>Did I? Oh yes. If we break down the requirements of a shopping cart (and here I\u2019m simplifying it to just be those items a user can request as hardware), what do we have?<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li>An ability to create forms that can capture the requests users will make \u2013 hopefully this blog has demonstrated this to some degree.<\/li><li>An ability to know what we can request \u2013 We\u2019ll be looking at this in the Summer when we attempt to integrate our <a href=\"https:\/\/snipeitapp.com\/\">Snipe-IT<\/a> asset management system with RT. This will give us access to the complete range of hardware options a user could request<\/li><li>A way to store my requests as a draft before I decide to purchase. Jon\u2019s previous blog post about <a href=\"https:\/\/blog.lboro.ac.uk\/middleware\/blog\/office365\/implementing-change-management-in-rt\">change<\/a>, showed a change lifecycle with a draft status that works in this manner. Hypothetically we can create a queue with a lifecycle that only has the statuses of \u201cdraft\u201d, &#8220;cancel&#8221;, and &#8220;purchase&#8221;, setup in such a way that only the owner can see their tickets in this queue. Any change of status away from draft kicks off actions that either move the ticket to a different queue that begins the purchasing process, or wipes it out.<\/li><li>A way to add and take away options whilst in draft \u2013 this will require some thought and no doubt a bit of Perl\/jQuery hackery, but the TicketSQL query builder has similar functionality in the way it adds and removes parts of the SQL query.<\/li><li>Running totals \u2013 again this would depend on how well you\u2019re managing the data for things that can be requested, but if its available it shouldn\u2019t be too much of an issue to add in<\/li><\/ol>\n\n\n\n<p>A lot\nof these still need thought, but none would appear implausible and it\u2019s the\ndirection we\u2019ll be heading over the next few months, as we begin to look at\nadding assets to our RT and what we can do by combining them with requests.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>We returned to Best Practical\u2019s Request Tracker (RT) as our service management tool, last year, with a remit to provide 3 processes which, when combined, would give us a workable service management system and allow our processes to expand and &hellip; <a href=\"https:\/\/blog.lboro.ac.uk\/middleware\/blog\/rt\/implementing-request-management-in-rt-quest-for-the-shopping-cart-part-1\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[70],"tags":[25,71,68],"class_list":["post-859","post","type-post","status-publish","format-standard","hentry","category-rt","tag-open-source","tag-request-management","tag-rt"],"_links":{"self":[{"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/posts\/859","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=859"}],"version-history":[{"count":24,"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/posts\/859\/revisions"}],"predecessor-version":[{"id":898,"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/posts\/859\/revisions\/898"}],"wp:attachment":[{"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/media?parent=859"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/categories?post=859"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.lboro.ac.uk\/middleware\/wp-json\/wp\/v2\/tags?post=859"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}