merging plain text into HTML and not lookin like crap
First time posting here....not sure I'm posting this in the right forum, or if there is a right forum. This is gonna be a fairly long post I think as I try and explain this. It's a work thing that i'm struggling to find an answer to.
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 shit. 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.