Blank Ticket Emails

All,

When certain users create tickets by emailing RT, the auto generated
ticket-open scrip (that goes to the AdminCCs) is blank (The Transaction
Has No Content), however you can see the content when viewing the ticket
via the WebUI.

Why does this happen only on certain tickets? Is it the format that the
email is sent in?

Stevo

Stevo wrote:

All,

When certain users create tickets by emailing RT, the auto generated
ticket-open scrip (that goes to the AdminCCs) is blank (The Transaction
Has No Content), however you can see the content when viewing the ticket
via the WebUI.

I’ve noticed this problem too. It happens when the MUA generates a
message without a text/plain component. RT treats the other parts
(text/html, for example) as attachments and displays them inline in the
web GUI, but since there was no plain text, RT doesn’t store a plain
text transaction.

I suppose we could go off at this point and ask why a mailreader would
EVER send a message without a plain text portion…

Rick R.

When certain users create tickets by emailing RT, the auto generated
ticket-open scrip (that goes to the AdminCCs) is blank (The
Transaction Has No Content), however you can see the content when
viewing the ticket via the WebUI.

I’ve seen this too, and it’s even in BP’s RT -
http://rt3.fsck.com/Ticket/Display.html?id=5351

Cheers
Toby

When certain users create tickets by emailing RT, the auto generated
ticket-open scrip (that goes to the AdminCCs) is blank (The
Transaction Has No Content), however you can see the content when
viewing the ticket via the WebUI.

I’ve seen this too, and it’s even in BP’s RT -
http://rt3.fsck.com/Ticket/Display.html?id=5351

In our installation, it happens when the two following conditions are
met:

  • the initial mail has a multipart/alternative section (i.e., the text
    is available in both evil HTML and plain text)
  • there is an attachment (i.e., a third MIME part)

When the second condition is not met, the reply includes text from both
the multipart/altervative parts, thus duplicating the initial mail.

In order to fix that, one should teach RT and MIME::Tools what to do
with multipart/alternative mails. It’s not enough of a problem for me
to care about looking into that, though.

Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I’ll go where I like, I’ll know where I want
to be, but maybe for now I’ll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.