developing a ticketing system to process website change requests (aka you’ve got mail)

Ever since we launched our site re-design, we’ve had a pretty steady flow internal change requests – add links, change fonts, re-style buttons, adjust layouts, modify permissions, etc.

We were trying to process these requests through a ticketing system that we built on our staff intranet in Drupal 6 – it basically allowed us to toggle tickets between open/closed and send emails when we were finished. With requests piling up (some of which overlapped with one another and/or were vaguely articulated and/or were out of our control anyways) this system wasn’t cutting it. We decided to scrap it and develop a new workflow in Drupal 7 with three questions in mind:

1) How can the requestor  clearly communicate what it is they actually want us to do
2) How can we clearly communicate what it is we’re actually doing
3) And how can we, as the general put it, start “hitting a small nail with an awfully big hammer”

The first two issues were solved easily enough: we enabled comments on the “Web Request” content type. When someone creates a node of that type, we can sniff out what they need with some probing in the comments area. The comments allow for transparent dialogue, so long as you have an effective method for distribution.

Enter the awfully big hammer…

Using a combination of rules, views, display suite and user reference fields, we gave node authors the ability to create email lists specific to the requests they create. With the click of a button they can message as many of their colleagues as they choose, giving them the gift of email at every step of the request.

Here’s how we did it:

First we created a form – we set up a content type for “Web Requests” – we were going to use entityforms but couldn’t since we needed commenting. We added fields for the data we wanted to collect (request title, details, link, and screenshots). We also created administrative fields (for things like UX data, project tagging, etc.) that are only visible to the web team, and therefore don’t appear on the node/add form that requestors use.

requestform

The most important field (for the email list) is the user reference field – what we termed “Stakeholders” is a selection of users of a given role formatted as checkboxes, with no restriction on the number of values.

users

The stakeholders appear on the form listed by name – that works for the users filling out the form, but not for rules, which will need their email addresses. Using display suite, we can configure a custom output for the stakeholders field when it is used as a token. In the “Manage Display” screen, you can specify custom display settings. Since we’ll be using tokens in the rules and views configurations we want to customize that to get the user’s email.

displaysuiteconfig1

So the token display for the field needs to output [user:mail]

displaysuiteconfig2

With the content type and fields configured, we’re ready for rules.

We want “Stakeholders” to be notified when a new request is created. So, we add a rule that reacts on saving new content and triggers an email message. By adding a condition that states that the content has the stakeholder field, we can get the token (mentioned above) and use that as one of the recipients for the email. But the email action will only pass through one of the values. That means only one person will be emailed, and that’s not good enough – we need everyone getting these emails. Rules allows us to loop actions, but not without a view that contextually displays content, which in this case is a list of stakeholder email address.

So we create a new view of content – the only field we need is a stakeholders field that has a custom formatter of tokenized text and outputs [user:mail]

viewsfield

The next step is to set a contextual filter that acts on the content node id (nid) – this should generate a list of stakeholder email address per node. Preview it to make sure by passing the view a nid.

viewsruledisplay

In order to call the view in rules, we have to give it a rules display. This also allows you to specify row variables – the important thing in this case is that we use the rendered result and the data type is text.

viewsrulevariable

With the view in place, we can go back to the rule we created and call it as a views loop.

viewsloop

Add the email action to that loop and you’re set.

rule-2

Each event that triggers an email will have its own rule, but you can use the same view/view loop structure for all of them, except comments. To get the stakeholder addresses to work in an email that’s set off by a comment, you have to create another view. This will be a view of comments that is configured almost identically to the stakeholder view, but with a relationship that joins comments to content so that you can use the nid filter.

commentsview-2

This entry was posted in Planet_Drupal and tagged , , , , , , . Bookmark the permalink.

5 Responses to developing a ticketing system to process website change requests (aka you’ve got mail)

  1. Greg Anderson says:

    You might also consider looking at the support (https://drupal.org/project/support) module. A colleague here at work is using that + og to build a support site. It’s not live yet, but looks promising.

    • hslweb says:

      Support is a great module – we probably could have used it for a starting point – this system is nice in that it allows some very fine-grained adjustments to replicate our organizational workflow… not sure if this is a great answer or not, however we are fairly pleased with the result

  2. Ian Thomas says:

    What made you choose Drupal, rather than one of the hundreds of specialised ticketing/bug tracking systems?

    Did you consider the project module?

    • hslweb says:

      one reason is to keep all information in a single silo – ticketing and ticket responses are now discoverable from the intranet without having to tie in another specialized tool. Also because our librarians are a persnickety lot it helps to be able to customize our tool specifically to our organizational needs.

    • hslweb says:

      also – project seems pretty cool, but more specifically tailored to code release, the bells and whistles we have added involve a bit of human interaction and responses.. project might have been a good starting point, however I’m very pleased with how everything we’ve developed works nicely with features and is pretty simple to export.