Hi all,
we just realized that the autoreply on ticket creation did not work for
one of our queues.
The reason was that $Ticket->QueueObj->Tag was used in the template
which made it fail silently. This is very likely related to the moving
of the Branded Queue Module into core.
While the reason was readily apparent when looking into the log files,
silentely failing is, imo, not an option. RT should, again imo, send
email to rtmaster informing him/her of the situation and should log the
failure with the ticket. This could be important in case there is an
argument over who sent what at what time.
Thanks yet again,
Richard
Hi all,
we just realized that the autoreply on ticket creation did not work
for
one of our queues.
The reason was that $Ticket->QueueObj->Tag was used in the template
which made it fail silently. This is very likely related to the moving
of the Branded Queue Module into core.
While the reason was readily apparent when looking into the log files,
silentely failing is, imo, not an option. RT should, again imo, send
email to rtmaster informing him/her of the situation and should log
the
failure with the ticket. This could be important in case there is an
argument over who sent what at what time.
I’d certainly take a patch to add that as an optional feature, though
it’s somewhat at odds with RT’s error logging philosophy. Instead, you
might want to have a log summarization tool mailing daily or hourly RT
log failures.
though it’s
somewhat at odds with RT’s error logging philosophy. Instead, you might want
to have a log summarization tool mailing daily or hourly RT log failures.
Normally, I agree that logging should be done outside of the user interface. In
this case though, a basic function silently fails. As this can lead to
‘I sent you
$veryimportantinfo’ ‘You did not’ ‘I can prove it, wait I can’t!’
situations, I consider
this a Very Bad Thing That Should Never Happen.
Also, while I now know what to look for, others will not. If the same happens to
them… Especially as the offending variable was not mentioned in the release
or the upgrade notes, this is bound to happen more than once.
Richard
though it’s
somewhat at odds with RT’s error logging philosophy. Instead, you
might want
to have a log summarization tool mailing daily or hourly RT log
failures.
Normally, I agree that logging should be done outside of the user
interface. In
this case though, a basic function silently fails.
I’d love to see an optional RT extension which allows administrators
to mail errors and exceptions. It may be as simple as a bit of
Log::Dispatch configuration.
As this can lead to
‘I sent you
$veryimportantinfo’ ‘You did not’ ‘I can prove it, wait I can’t!’
situations, I consider
this a Very Bad Thing That Should Never Happen.
Also, while I now know what to look for, others will not. If the
same happens to
them.
Especially as the offending variable was not mentioned in the release
or the upgrade notes, this is bound to happen more than once.
Can you paste the snippet that went awry? I have an idea of something
that may make you happy and be a fairly reasonable middle ground, but
I need to know more about exactly how you got it to fail so badly.
I’d love to see an optional RT extension which allows administrators to mail
errors and exceptions. It may be as simple as a bit of Log::Dispatch
configuration.
Yes, that would be a nice feature, agreed 
Can you paste the snippet that went awry? I have an idea of something that
may make you happy and be a fairly reasonable middle ground, but I need to
know more about exactly how you got it to fail so badly.
I will do so tomorrow, yes.
Thanks,
Richard
Can you paste the snippet that went awry? I have an idea of something that
may make you happy and be a fairly reasonable middle ground, but I need to
know more about exactly how you got it to fail so badly.
The minimal snippet, as in my initial mail, is
$Ticket->QueueObj->Tag
which makes RT complain with
[Mon Jul 14 21:03:01 2008] [error]: Template parsing error:
RT::Queue::Tag Unimplemented in Text::Template::GEN0. (template line
10)
Stack:
[/usr/local/share/perl/5.8.8/DBIx/SearchBuilder/Record.pm:495]
[template:10]
[/usr/local/rt3/bin/…/lib/RT/Template_Overlay.pm:432]
[/usr/local/rt3/bin/…/lib/RT/Template_Overlay.pm:336]
[/usr/local/rt3/bin/…/lib/RT/Template_Overlay.pm:312]
[/usr/local/rt3/bin/…/lib/RT/Action/SendEmail.pm:158]
[/usr/local/rt3/bin/…/lib/RT/Action/Autoreply.pm:66]
[/usr/local/rt3/bin/…/lib/RT/ScripAction_Overlay.pm:230]
[/usr/local/rt3/bin/…/lib/RT/Scrip_Overlay.pm:435]
[/usr/local/rt3/bin/…/lib/RT/Scrips_Overlay.pm:240]
[/usr/local/rt3/bin/…/lib/RT/Transaction_Overlay.pm:169]
[/usr/local/rt3/bin/…/lib/RT/Record.pm:1419]
[/usr/local/rt3/bin/…/lib/RT/Ticket_Overlay.pm:648]
[/usr/local/rt3/bin/…/lib/RT/Interface/Email.pm:1352]
[/usr/local/rt3/share/html/REST/1.0/NoAuth/mail-gateway:61]
(/usr/local/rt3/bin/…/lib/RT/Template_Overlay.pm:427)
Said variable was in line 10 of the template.
If there is any more info you need, please poke me
Richard
Can you paste the snippet that went awry? I have an idea of
something that
may make you happy and be a fairly reasonable middle ground, but I
need to
know more about exactly how you got it to fail so badly.
The minimal snippet, as in my initial mail, is
$Ticket->QueueObj->Tag
which makes RT complain with
[Mon Jul 14 21:03:01 2008] [error]: Template parsing error:
RT::Queue::Tag Unimplemented in Text::Template::GEN0. (template line
10)
What I’d like to see is a patch that wraps each of the template’s
blocks in an ‘eval {}’ such that we could trap a failing block and
keep going. I suspect it’s going to be necessary to subclass
Text::Template and override a sub.
I think it’s documented in upgrade doc that the new method is
SubjectTag, not just Tag. ok… took a look and it’s not documented.
Doc is docs/queue_subject_tag.pod which is referenced from UPGRADING.
At the bottom upgrading instructions for users of the extension. Add
step 4) convert templates to use new method ->SubjectTag instead of
->Tag.On Mon, Jul 28, 2008 at 2:48 PM, Richard Hartmann richih.mailinglist@gmail.com wrote:
On Sun, Jul 27, 2008 at 01:46, Jesse Vincent jesse@bestpractical.com wrote:
Can you paste the snippet that went awry? I have an idea of something that
may make you happy and be a fairly reasonable middle ground, but I need to
know more about exactly how you got it to fail so badly.
The minimal snippet, as in my initial mail, is
$Ticket->QueueObj->Tag
which makes RT complain with
[Mon Jul 14 21:03:01 2008] [error]: Template parsing error:
RT::Queue::Tag Unimplemented in Text::Template::GEN0. (template line
10)
Stack:
[/usr/local/share/perl/5.8.8/DBIx/SearchBuilder/Record.pm:495]
[template:10]
[/usr/local/rt3/bin/…/lib/RT/Template_Overlay.pm:432]
[/usr/local/rt3/bin/…/lib/RT/Template_Overlay.pm:336]
[/usr/local/rt3/bin/…/lib/RT/Template_Overlay.pm:312]
[/usr/local/rt3/bin/…/lib/RT/Action/SendEmail.pm:158]
[/usr/local/rt3/bin/…/lib/RT/Action/Autoreply.pm:66]
[/usr/local/rt3/bin/…/lib/RT/ScripAction_Overlay.pm:230]
[/usr/local/rt3/bin/…/lib/RT/Scrip_Overlay.pm:435]
[/usr/local/rt3/bin/…/lib/RT/Scrips_Overlay.pm:240]
[/usr/local/rt3/bin/…/lib/RT/Transaction_Overlay.pm:169]
[/usr/local/rt3/bin/…/lib/RT/Record.pm:1419]
[/usr/local/rt3/bin/…/lib/RT/Ticket_Overlay.pm:648]
[/usr/local/rt3/bin/…/lib/RT/Interface/Email.pm:1352]
[/usr/local/rt3/share/html/REST/1.0/NoAuth/mail-gateway:61]
(/usr/local/rt3/bin/…/lib/RT/Template_Overlay.pm:427)
Said variable was in line 10 of the template.
If there is any more info you need, please poke me
Richard
List info: The rt-devel Archives
Best regards, Ruslan.
Doc is docs/queue_subject_tag.pod which is referenced from UPGRADING.
At the bottom upgrading instructions for users of the extension. Add
step 4) convert templates to use new method ->SubjectTag instead of
->Tag.
Not quite:
=head2 For everyone who is upgrading
[…]
“There is no need to reply to this message right now. Your ticket has been
assigned an ID of [{$rtname} #{$Ticket->id()}].”
Change this line to read:
“There is no need to reply to this message right now. Your ticket has been
assigned an ID of [{ $Ticket->QueueObj->SubjectTag || $rtname }
#{$Ticket->id()}].”
The docs for users of RT-Extension-BrandedQueues does not mention that
particular variable, either. Nor does etc/upgrade/3.8-branded-queues-extension
seem to refer to it.
It might well be that I misunderstood something, though. If that is the case,
please tell me
Thanks for looking into this,
RIchard
Check out new version of the doc:
http://svn.bestpractical.com/cgi-bin/index.cgi/bps/view/rt/3.8/trunk/docs/queue_subject_tag.podOn Mon, Jul 28, 2008 at 7:13 PM, Richard Hartmann richih.mailinglist@gmail.com wrote:
On Mon, Jul 28, 2008 at 15:26, Ruslan Zakirov ruz@bestpractical.com wrote:
Doc is docs/queue_subject_tag.pod which is referenced from UPGRADING.
At the bottom upgrading instructions for users of the extension. Add
step 4) convert templates to use new method ->SubjectTag instead of
->Tag.
Not quite:
=head2 For everyone who is upgrading
[…]
“There is no need to reply to this message right now. Your ticket has been
assigned an ID of [{$rtname} #{$Ticket->id()}].”
Change this line to read:
“There is no need to reply to this message right now. Your ticket has been
assigned an ID of [{ $Ticket->QueueObj->SubjectTag || $rtname }
#{$Ticket->id()}].”
The docs for users of RT-Extension-BrandedQueues does not mention that
particular variable, either. Nor does etc/upgrade/3.8-branded-queues-extension
seem to refer to it.
It might well be that I misunderstood something, though. If that is the case,
please tell me
Thanks for looking into this,
RIchard
Best regards, Ruslan.
Check out new version of the doc:
http://svn.bestpractical.com/cgi-bin/index.cgi/bps/view/rt/3.8/trunk/docs/queue_subject_tag.pod
I would write $Ticket->QueueObj->SubjectTag instead of SubjectTag in the last
line of the doc, but else, it looks good
Richard
done. thank you.On Mon, Jul 28, 2008 at 8:53 PM, Richard Hartmann richih.mailinglist@gmail.com wrote:
On Mon, Jul 28, 2008 at 17:38, Ruslan Zakirov ruz@bestpractical.com wrote:
Check out new version of the doc:
http://svn.bestpractical.com/cgi-bin/index.cgi/bps/view/rt/3.8/trunk/docs/queue_subject_tag.pod
I would write $Ticket->QueueObj->SubjectTag instead of SubjectTag in the last
line of the doc, but else, it looks good
Richard
Best regards, Ruslan.