I am having an awful time with getting users to remove quoted text from
replies. I’ve begun looking at rt-mailgate code to figure a way to remove
the “---- Original Message ----” and below it that Outlook creates when you
hit reply.
the write_down_message() function seems to either create a temp file or use
memory to take the message from STDIN. I thought about stripping it down
during reading from STDIN but its being read in binmode 8k at a time, so the
“---- Original Message ----” might be broken across chunks. So that won’t work.
After write_down_message(), I could simply regex it into oblivion – if its
in memory. If its in the temp file… it doesn’t seem like a scalable
solution to read the temp file and re-write it. We’ve already written the
message to the temp file once.
What I’d like to do is go back to write_down_message() and look for the key
line, and do some sneaky read-ahead of a few bytes into the next buffer if
the end of the buffer could be a broken “Original Message” line, and then
seek back to the beginning of that chunk if it isn’t.
Finally, I suspect that Outlook puts attachments after the body, in which
case an email reply that contains attachments would get the attachments
dropped unless I keep reading for a MIME boundary, in which case I have to
know what the boundary is in the first place, which means parsing the header.
Has anyone else done anything like this already, or am I venturing into
uncharted waters here? Does my plan sound decent, or am I crazy for even
thinking of it?
– ============================
Tom Lahti
BIT Statement LLC
(425)251-0833 x 117
http://www.bitstatement.net/
– ============================
I am having an awful time with getting users to remove quoted text
from
replies. I’ve begun looking at rt-mailgate code to figure a way to
remove
the “---- Original Message ----” and below it that Outlook creates
when you
hit reply.
the write_down_message() function seems to either create a temp file
or use
memory to take the message from STDIN. I thought about stripping it
down
during reading from STDIN but its being read in binmode 8k at a
time, so the
“---- Original Message ----” might be broken across chunks. So that
won’t work.
After write_down_message(), I could simply regex it into oblivion –
if its
in memory. If its in the temp file… it doesn’t seem like a scalable
solution to read the temp file and re-write it. We’ve already
written the
message to the temp file once.
What I’d like to do is go back to write_down_message() and look for
the key
line, and do some sneaky read-ahead of a few bytes into the next
buffer if
the end of the buffer could be a broken “Original Message” line,
and then
seek back to the beginning of that chunk if it isn’t.
Finally, I suspect that Outlook puts attachments after the body, in
which
case an email reply that contains attachments would get the
attachments
dropped unless I keep reading for a MIME boundary, in which case I
have to
know what the boundary is in the first place, which means parsing
the header.
I don’t think it is crazy to want to solve the problem but I suspect
you would regret the method by which you are considering solving it.
I haven’t tried this, but if I were going to I would do it on
retrieval and display rather than by altering the message on the way
in. That way when it turns out your parsing is imperfect you haven’t
damaged the original and you might even offer the user a way to
recover by peeking at the original.
Cheers
Adam Clarke
www.strategicdata.com.au
in. That way when it turns out your parsing is imperfect you haven’t
damaged the original and you might even offer the user a way to
recover by peeking at the original.
More specifically, I’d recommend doing it the same way RT handles
letting users see the outgoing messages. Don’t show it on Display.html,
but do on History.html.
Incidentally, if you manage to get a robust version of this working I’d
be interested in adopting it too.
Cambridge Energy Alliance: Save money. Save the planet.
There are a number of interesting mods that I’ve noted he’s working on that I’m interested in. (For instance the scrip changes to enforce only requesters can change the ticket’s status, etc.
Gary L. Greene, Jr.
IT Operations
Minerva Networks, Inc.
Tel: (408) 240-1239
Cell: (650) 704-6633
Gary Greene wrote:
There are a number of interesting mods that I’ve noted he’s working on
that I’m interested in. (For instance the scrip changes to enforce only
requesters can change the ticket’s status, etc.
Actually, I accomplished that with just scrips. And then I convinced
ownership it was a bad idea, because it meant that people working on tickets
could no longer use their ticket list as a “to-do” list, and it wasn’t
really needed because a requestor can always re-open a resolved ticket by
just replying to the email.
They were actually trying to solve another issue where a requestor was not
notified when a ticket was resolved. That’s what happens when owners try to
play systems analyst without telling the engineers what the actual problem
is and just try to ask for what they think the best solution would be instead.
However, if you’re dying for it all you have to do it apply a scrip to
condition “On Resolve” with action prep:
return 1;
and action cleanup:
return 1 if $self->TransactionObj->IsInbound;
$self->TicketObj->_Set(Field => ‘Status’, Value => ‘open’, RecordTransaction
=> 0);
return 1;
And then, when someone other than a requestor resolves a ticket, the cleanup
code sets it back to open. The IsInbound method of the Transaction object
returns true if the transaction was generated by a requestor.
Then you just do the same thing in reverse for conditions that generate
‘resolved’ emails so you aren’t sending out an email when a non-requestor
tries to resolve. I tried playing around with template code to send
different emails whether it was a requestor or not (Dear requestor, XXX
would like you to resolve ticket YYY), but Text::Template parsing is rather
limited and it never worked the way I wanted it to. Notably, you can’t have
a conditional (like an ‘if’ statement) span blocks.
– ============================
Tom Lahti
BIT Statement LLC
(425)251-0833 x 117
http://www.bitstatement.net/
– ============================