Tom’s Graphic Design Journal

So work has this help desk / ticket system. Very basic, but taking this conversation a step further...It could be any ticket system script you have on your server. I won't go into trac though -- but I know how it could be integrated just the same. I'm going to stick to PHP for now because this is the implementation used in my situation.

The help desk form has some specific fields related to the web site and then stores the ticket into our database and then e-mails it off to people on the development team. Basecamp doesn't have a ticketing system (STUPID - this is merely one reason why trac is infinitely better than basecamp) so our requests and e-mails are all separate from Basecamp. The project manager has to transcribe all the e-mails and store them in Basecamp for record keeping. Note now a time stamp discrepancy aside from it being very very time consuming.

So what to do? Well, there's a 3rd party site that has a ticketing system for Basecamp at http://bctix.com. It's ok and completely non-invasive...but it's also limited and non-intuitive. Plus not integrated with your personal site or Basecamp in terms of filling out a ticket support form.

No one besides the signals there are going to make a perfect integration into their system. They need to do that. Although we can copy their css/html and layouts to make our system "look" like it's part of Basecamp...minus the URL. In my case we have our own ticket system that looks like some tools on the client's site and not like Basecamp at all. No big deal. However...it is familiar looking to the client and the form is completely customized for the client's needs.

Now what the bctix site does is puts in the title of each message, numbers that essentially equate to different things like categories and status. Ugly and more important very easy to screw up. The other downside is that you have to use the bctix site's forms.

My super slick solution (which was hours of pain) is to add on to our already existing form ... note for others out there, this means add on to your already existing ticket system ... and make it send off to Basecamp via the API at the same time it saved the ticket to the db and alerted the staff by e-mail. Cool. Easy. So then what? You have to go into basecamp to update the ticket or reply to it? No no no, here's the cool part (where the headache came into play)...

Along with e-mailing the proper people, there was another e-mail address tacked on to the CC which contained helpdesk-{basecamp ticket number}@domain.com. This wildcard e-mail address was then handled by a script on the server (Qmail was being used). This now leaves an address to reply to that is our "basecamp bridge" and what happens now is the server reads any e-mails coming back at it and takes the number past the hyphen ... which came from the response we got from the basecamp API when the initial ticket was made ... and adds a comment instead of a message using the Basecamp API. Now we have all replies from our e-mail programs automatically saved as comments (replies) in Basecamp under the appropriate message! It's by id number too so we can change the title of the message to file it or do whatever we want. We won't get messed up. 

Cool. So if you haven't figured out where I got a headache...it was in the server setup to receive e-mails to a wildcard address and process the mail through a PHP script. The other part that was difficult was all the regex matching to removed nested quotes from e-mails, privacy policy statements our company had at the bottom of our e-mails by default, etc. So in the end, it was just our replies that made it to the comments and not the same ticket repeated over and over. Very clean. 

So how'd we get the server to handle the e-mail? I partially followed this tutorial on evolt. I also looked up the Qmail manual/documentation which came in handy. Also note we are using Media Temple's DV server...So you need root access sadly. Unless -- your host is super cool and in your control panel you can forward e-mails to a PHP script...and also setup the catch-allo or wildcard aliases. I think that's possible somewhere under some shared host...it sounds possible at least, though rare...but think about people who can e-mail in their blog posts, right??

So in the .qmail file I basically made the setting to run a PHP script that analyzed the headers. At first I thought I'd be REAL sneaky and read the message-ID and references headers to see the e-mail thread and keep using that to distinguish between comments or replies. I also set a uid in the initial e-mail that was sent off from the help desk (which is still sent off). That didn't work out so well because different e-mail programs destroy headers. Almost all (if not all) e-mail programs remove any custom headers you set. So that's actually good -- note the uid I set now acts as the distinction between a brand new e-mail or a reply...because obviously replies will never have that uid, right?

So that's it. Our script basically reads the e-mail address in the header and grabs the id and uses that to call the Basecamp API to leave a comment on the message id. Voila. A very slick and transparent integration. I'll try to clean up my experiment and post something later.

   

So work has this help desk / ticket system. Very basic, but taking this conversation a step further...It could be any ticket system script you have on your server. I won't go into trac though -- but I know how it could be integrated just the same. I'm going to stick to PHP for now because this is the implementation used in my situation.

The help desk form has some specific fields related to the web site and then stores the ticket into our database and then e-mails it off to people on the development team. Basecamp doesn't have a ticketing system (STUPID - this is merely one reason why trac is infinitely better than basecamp) so our requests and e-mails are all separate from Basecamp. The project manager has to transcribe all the e-mails and store them in Basecamp for record keeping. Note now a time stamp discrepancy aside from it being very very time consuming.

So what to do? Well, there's a 3rd party site that has a ticketing system for Basecamp at http://bctix.com. It's ok and completely non-invasive...but it's also limited and non-intuitive. Plus not integrated with your personal site or Basecamp in terms of filling out a ticket support form.

No one besides the signals there are going to make a perfect integration into their system. They need to do that. Although we can copy their css/html and layouts to make our system "look" like it's part of Basecamp...minus the URL. In my case we have our own ticket system that looks like some tools on the client's site and not like Basecamp at all. No big deal. However...it is familiar looking to the client and the form is completely customized for the client's needs.

Now what the bctix site does is puts in the title of each message, numbers that essentially equate to different things like categories and status. Ugly and more important very easy to screw up. The other downside is that you have to use the bctix site's forms.

My super slick solution (which was hours of pain) is to add on to our already existing form ... note for others out there, this means add on to your already existing ticket system ... and make it send off to Basecamp via the API at the same time it saved the ticket to the db and alerted the staff by e-mail. Cool. Easy. So then what? You have to go into basecamp to update the ticket or reply to it? No no no, here's the cool part (where the headache came into play)...

Along with e-mailing the proper people, there was another e-mail address tacked on to the CC which contained helpdesk-{basecamp ticket number}@domain.com. This wildcard e-mail address was then handled by a script on the server (Qmail was being used). This now leaves an address to reply to that is our "basecamp bridge" and what happens now is the server reads any e-mails coming back at it and takes the number past the hyphen ... which came from the response we got from the basecamp API when the initial ticket was made ... and adds a comment instead of a message using the Basecamp API. Now we have all replies from our e-mail programs automatically saved as comments (replies) in Basecamp under the appropriate message! It's by id number too so we can change the title of the message to file it or do whatever we want. We won't get messed up. 

Cool. So if you haven't figured out where I got a headache...it was in the server setup to receive e-mails to a wildcard address and process the mail through a PHP script. The other part that was difficult was all the regex matching to removed nested quotes from e-mails, privacy policy statements our company had at the bottom of our e-mails by default, etc. So in the end, it was just our replies that made it to the comments and not the same ticket repeated over and over. Very clean. 

So how'd we get the server to handle the e-mail? I partially followed this tutorial on evolt. I also looked up the Qmail manual/documentation which came in handy. Also note we are using Media Temple's DV server...So you need root access sadly. Unless -- your host is super cool and in your control panel you can forward e-mails to a PHP script...and also setup the catch-allo or wildcard aliases. I think that's possible somewhere under some shared host...it sounds possible at least, though rare...but think about people who can e-mail in their blog posts, right??

So in the .qmail file I basically made the setting to run a PHP script that analyzed the headers. At first I thought I'd be REAL sneaky and read the message-ID and references headers to see the e-mail thread and keep using that to distinguish between comments or replies. I also set a uid in the initial e-mail that was sent off from the help desk (which is still sent off). That didn't work out so well because different e-mail programs destroy headers. Almost all (if not all) e-mail programs remove any custom headers you set. So that's actually good -- note the uid I set now acts as the distinction between a brand new e-mail or a reply...because obviously replies will never have that uid, right?

So that's it. Our script basically reads the e-mail address in the header and grabs the id and uses that to call the Basecamp API to leave a comment on the message id. Voila. A very slick and transparent integration. I'll try to clean up my experiment and post something later.