Hey Folks,

This is gonna be a fairly long post I think as I try and explain this. It's for work, but i'm struggling to find a way through it and am looking for ideas of any sort.

Here's the deal, I am the administrator of some incident management software (trouble ticketing program). When tickets are opened/closed on behalf of end-users the system generates emails that pull fields from the ticket (like incident description, close description, target resolution date, priority etc etc etc) into it.

Now the crappy part is that this system by default isn't smart enough to do HTML emails. It can only handle plain text which we all know looks horrible. Even more so, if the ticket description happens to be an email string, it's nearly impossible to decipher where the start and end of the incident descriptions are cause everything looks the same in plain text.

So....I found a neat piece of third-party software that is essentially a Win32 command line utility that sends email using SMTP. It allows me to send my emails in HTML.

Here's the simplified break down of how that happens:
1. Via the incident management software, a file gets written to disk in an HTML file (all html coding). In it, I can randomly pull field out of the ticket (incident description, solution, dates etc etc).
2. The incident management software writes the persons email address to a text file.
3. The incident management software then calls the win32 command line utility which then says, send an email using the HTML document created in step 1 and send it to the email address from step 2.

So that builds me a wonderfully formatted HTML email that looks about eleventy billion times better than the plain text.


The issue is....when I pull fields like the incident description, or solution which have potential to be very long, include email signatures, or be strings of emails long, they get pulled into the HTML file in plain text. When this plain text shows up in the middle of an HTML coded document it looks like . There's obviously no formatting to the plain text portion, so there's no carriage returns or anything. Everything is jumbled together. If the field has a short amount of info or a single paragraph, it's fine, but if not...you're screwed.



So....i'm looking for ideas to fix this.


1. Original idea was to put the description into an i-frame. That looks fantastic in the HTML document and fixes a number of things I didn't necessarily like. Porblem here is that Microsoft blocks iframes in emails as they're a security vulnerability. Makes sense.

2. I thought about trying to implement something similar to a custom URL protocol we built that allows us to use links in our emails directly to tickets....so people can click on them and it opens up the incident management software. But that would involve people clicking on something extra to see the description of their issue.

3. I have the ability to put the incident description and/or incident solution in an attachment attached to the email. That attachment could be plain text and would look fine, but as I mentioned earlier, plain text is sorta lame and that would still involve the end-user having to open something to see their attachments.

4. I've thought about only displaying 3 or 4 lines of their description and linking them to the Self-Service webpage that gives all this info and more, but unfortunately the viewing window for the description is sorta small and, I don't think I have a way to link directly to the ticket in question as it involves logging into the site first.

5. I'm still researching this but don't know much about it: write the incident description to a seperate text file. Use a third party program to convert that file to HTML (via command line), then the tricky part would be inserting this newly created HTML file/coding into the original HTML file/coding that gets emailed to the end user. The description and solutions will always be inserted into the same point in the email, however, depending on the description, the email could become pages long which would mean the solution info could be anywhere.

On second thought, I'm not sure if on close we include both the incident description and solution, or just the solution. Either way the above would involve some scripting of sorts that I don't have the ability or knowledge to write...and am not even really sure if it's possible in the first place.

6. I don't have a 6...but i'm lookin for ideas....


Anyone got anything???

Thanks for the read if you by chance made it this far.

 

Gah...after who knows how many hours of searching, n researching possible scritps n related, someone asked why i didn't just use the <PRE> tag. Well geez....who woulda known this was soo easy. Too bad someone didn't mention it earlier.

<PRE> marks the text as "preformatted" -- all the spaces and carriage returns are rendered exactly as you type them.

Solves all my problems; keeps plain text formatted in an HTML email.

 

OK, turns out that <PRE> tag doesn't completely work as planned. It has no word-wrap. So for a paragraph - you might have to scroll like 10 screens over just to read to the end. That was like a day after i implemented it that I noticed.


Anywho, just recently I found another solution which I think will work. This one involves writing the description (the part that is plain text) into a text file, calling a program called AscToTab to convert it to HTML, From there, I can write the original email I had planned, but instead of pulling the description from the actual ticket system, I just pull in this html file I created.

It generally all works pretty well, though every once in a blue moon this converter program feels a need to bol something. All in all, it seems pretty simple and makes me wonder why I didn't try this option earlier. However, looking back, I did try it, but I didn't think I could pull a file into an email like I have here.

 

I think you are thinking into this way too much. Take a step back and consider a couple of things:

a) Users will rarely read the emails that are generated. Most people will only care about the problem being resolved. I get dozens of these types of emails at work, and each and every one of them gets deleted without a second though

b) Plain text should not be an issue. As long as the relevant information is there, you should be able to format the e-mail well enough for it to be readable.