Hi,
in our RT installation (4.0.6) we have a tool that sends e-mails to the
RT with Content-Type: multipart/alternative that I want to forward from
RT to all recipients. On the receiving end we have a scrip that
OnCorrespond notifies requestors, etc… I can make it send the
text/plain part easily, but I have troubles with the text/html part. I
have checked the templates.pod documentation where it states that if I
set the Content-Type inside the template to text/html, it will
autogenerate the multipart message and create the text/plain part by
itself. Which it does… but suboptimally at best. Is there a way to
just forward my handcrafted multipart message without much RT’s
interference?
Thank you.
Martin
in our RT installation (4.0.6) we have a tool that sends e-mails to the
RT with Content-Type: multipart/alternative that I want to forward from
RT to all recipients. On the receiving end we have a scrip that
OnCorrespond notifies requestors, etc… I can make it send the
text/plain part easily, but I have troubles with the text/html part. I
have checked the templates.pod documentation where it states that if I
set the Content-Type inside the template to text/html, it will
autogenerate the multipart message and create the text/plain part by
itself. Which it does… but suboptimally at best. Is there a way to
just forward my handcrafted multipart message without much RT’s
interference?
4.2 does a much better job passing along multipart mails.
You cannot easily force RT to send a custom alternative email,
especially not in 4.0.
-kevin
4.2 does a much better job passing along multipart mails.
You cannot easily force RT to send a custom alternative email,
especially not in 4.0.
Thanks for your response. I am not necessarily looking for an easy way
to make RT do my bidding and upgrade is not an option right now. In a
way, I do not really need to use the template at all, incoming messages
are formated just as I want them to be.
I wanted to create a scrip that would just forward the mail to
requestors (that are set on ticket create via the REST interface). But I
have some problems with it.
This is my scrip:
package RT::Action::ForwardGatewayReport;
use strict;
use warnings;
use base qw(RT::Action::SendEmail);
use Email::Address;
sub Prepare {
my $self = shift;
# Set recipients to ticket requestors
$self->SetRecipients();
return 1;
}
sub Commit {
my $self = shift;
my $mail;
???
What here?
???
my $rc = $self->SendMessage($mail);
if ($rc && RT->Config->Get(‘RecordOutgoingEmail’))
{
$self->RecordOutgoingMailTransaction($mail);
}
return $rc;
}
I have tried to recreate the $mail with transaction attachments read as
ContentAsMIME() but I have never managed to successfully extract the
original email.
The other thing I have in mind is to create a new mime object of type
multipart/alternative and insert those two text/plain and text/html
parts. But that seems to me a bit cumbersome, given that everything is
already there.
Other issue I am having is that using this script, the correspondence
gets recorded gazzilion times and not just once. Do you have any idea,
where the problem might be?
Thanks,
Martin
4.2 does a much better job passing along multipart mails.
You cannot easily force RT to send a custom alternative email,
especially not in 4.0.
Thanks for your response. I am not necessarily looking for an easy way
to make RT do my bidding and upgrade is not an option right now. In a
way, I do not really need to use the template at all, incoming messages
are formated just as I want them to be.
On Create Notify Requestors with template Corresopnd
which will relay your mail to the requestors during creation.
Your Scrip is honestly likely to cause all the problems you saw.
Or just set your requestors and then correspond on the ticket with
your content.
4.2 will do a better job of not mangling your mail. Reading the
outgoing mail transaction though is almost guaranteed to fail.
Just use normal RT correspond actions.
-kevin
Dne 7.2.2014 17:52, Kevin Falcone napsal(a):
Thanks for your response. I am not necessarily looking for an easy way
to make RT do my bidding and upgrade is not an option right now. In a
way, I do not really need to use the template at all, incoming messages
are formated just as I want them to be.
On Create Notify Requestors with template Corresopnd
which will relay your mail to the requestors during creation.
Your Scrip is honestly likely to cause all the problems you saw.
Or just set your requestors and then correspond on the ticket with
your content.
Correspond template is not working for me as I would like it to work -
i.e. in the template I have RT-Attach-Message: Yes, but if I don’t
supply body in the text of the template (because I don’t want to insert
any other text, except the one I have received), no mail is sent.
Can I do something with it?
Another thing is a the RT-Ataach-Message mechanism. If I take a look at
the sent message from within the RT I see two RT-Attachment headers.
Does that mean that those two attachments are going to be sent
separately and not inside multipart/alternative?
4.2 will do a better job of not mangling your mail. Reading the
outgoing mail transaction though is almost guaranteed to fail.
Just use normal RT correspond actions.
By outgoing mail transaction, do you mean the Correspondence
transaction? Because I have previously altered the Notify.pm scrip
(albeit to much lesser extent) to add one special attachment to each
outgoing e-mail and I had no problems with it at all…
Thanks,
Martin
Hmm… so I have just hacked the Template.pm _DowngradeFromHTML() to
check for multipart/alternative in transaction and supply the text/plain
part from it, instead of using the HTML::TreeBuilder and
HTML::FormatText. Seems to work like a charm.
Now I wonder, when it’s going to bite me 
Martin
Hmm… so I have just hacked the Template.pm _DowngradeFromHTML() to
check for multipart/alternative in transaction and supply the
text/plain part from it, instead of using the HTML::TreeBuilder and
HTML::FormatText. Seems to work like a charm.
Now I wonder, when it’s going to bite me
In the future, if you report bugs, please mention this local
modification.
-kevin