bug in HTML::FormatText::WithLinks::AndTables stops scrips working

RT Users
1

Hi

We are using rt4.2.1

In the past weeks, we received considerable complaints from our staff that
their comments and corresponds are not delivered to the requestors (i.e. on
correspond notify requestors).

As we had upgraded from 3.8 to 4.2.1, we thought this might be caused by the
upgrade…

But Checking different things I found the below in the logs:

[3778] [Sat Nov 30 09:24:26 2013] [warning]: Use of uninitialized value $_
in concatenation (.) or string at
/usr/local/lib/perl5/site_perl/5.14.2/HTML/FormatText/With

Links/AndTables.pm line 211.
(/usr/local/lib/perl5/site_perl/5.14.2/HTML/FormatText/WithLinks/AndTables.p
m:211)

[3778] [Sat Nov 30 09:24:26 2013] [error]: Scrip Prepare 6 died. - Can’t
call method “content” on an undefined value at
/usr/local/lib/perl5/site_perl/5.14.2/HTML/Form

atText/WithLinks/AndTables.pm line 217.

Stack:

[/usr/local/lib/perl5/site_perl/5.14.2/HTML/FormatText/WithLinks/AndTables.p
m:217]

[/usr/local/lib/perl5/site_perl/5.14.2/HTML/FormatText/WithLinks/AndTables.p
m:101]

[/usr/local/lib/perl5/site_perl/5.14.2/HTML/FormatText/WithLinks/AndTables.p
m:83]

[/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:1777]

[/opt/rt4/sbin/…/lib/RT/Template.pm:666]

[/opt/rt4/sbin/…/lib/RT/Template.pm:421]

[/opt/rt4/sbin/…/lib/RT/Action/SendEmail.pm:139]

[/opt/rt4/sbin/…/lib/RT/Action/Notify.pm:69]

[/opt/rt4/sbin/…/lib/RT/ScripAction.pm:222]

[/opt/rt4/sbin/…/lib/RT/Scrip.pm:561]

[/opt/rt4/sbin/…/lib/RT/Scrips.pm:358]

[/opt/rt4/sbin/…/lib/RT/Transaction.pm:189]

[/opt/rt4/sbin/…/lib/RT/Record.pm:1626]

[/opt/rt4/sbin/…/lib/RT/Ticket.pm:1611]

[/opt/rt4/sbin/…/lib/RT/Ticket.pm:1507]

[/opt/rt4/local/plugins/RT-Extension-CommandByMail/lib/RT/Interface/Email/Fi
lter/TakeAction.pm:374]

[/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:1531]

[/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:1345]

Working more, I found that, when HTML::FormatText::WithLinks::AndTables
could not parse the message and returned error, the scrips stop working

In this special case, the problem could be generated very easy. Consider
having 2 empty html tables which one of them enclosed in the other:

If the message contains such structure,
HTML::FormatText::WithLinks::AndTables would fail.

Sample code to test:

use HTML::FormatText::WithLinks::AndTables;

if (!(defined($ARGV[0]))) {print print “please enter htmlfile”\n";exit;}

$html=cat $ARGV[0];

my $text = HTML::FormatText::WithLinks::AndTables->convert($html);

print $text;

something regarding this bug is here:
Bug #87457 for HTML-FormatText-WithLinks-AndTables: Issue with empty tables, uninitialized $new_text in line 230 (v0.02) but I’ve not applied
it.

First, does anybody else faced with such problem? i.e.
incorrect/incompatible html mail from a customer and/or staff which causes
scrips fail to run scrips? I could not figure it out if this exists in 3.8.
or not.

Second, is that rational behavior for RT? I believe even if such module
failed, at lease scrips should continue working. (maybe it should be
submitted to rt-bugs)

-payam

2

In the past weeks, we received considerable complaints from our staff
that their comments and corresponds are not delivered to the
requestors (i.e. on correspond notify requestors).
[snip]
Working more, I found that, when
HTML::FormatText::WithLinks::AndTables could not parse the message and
returned error, the scrips stop working

In this special case, the problem could be generated very easy.
Consider having 2 empty html tables which one of them enclosed in the
other:
[snip]

Excellent debugging.

First, does anybody else faced with such problem? i.e.
incorrect/incompatible html mail from a customer and/or staff which
causes scrips fail to run scrips? I could not figure it out if this
exists in 3.8. or not.

RT 4.2 is the first to attempt to automatically provide downgraded
text/plain alternatives to text/html mail; as such, this did not exist
in RT 3.8.

Second, is that rational behavior for RT? I believe even if such
module failed, at lease scrips should continue working. (maybe it
should be submitted to rt-bugs)

Absolutely a bug; we should be at least sending the HTML part. Please
try https://github.com/bestpractical/rt/commit/8807f0d.patch

How are your staff generating the problematic HTML, out of curiosity?
Is the CKeditor generating that, or are you pasting in from Word or some
other source?

  • Alex
3

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-

In the past weeks, we received considerable complaints from our staff
[snip]

Absolutely a bug; we should be at least sending the HTML part. Please
try https://github.com/bestpractical/rt/commit/8807f0d.patch

How are your staff generating the problematic HTML, out of curiosity?
Is the CKeditor generating that, or are you pasting in from Word or some
other source?

Hi
Thank you for the patch. I forwarded it to my colleague to apply and test it.
Regarding your question, it had been not generated through CKeditor. I had develop a small code and put it in the Ticket page which shows up 2 links for comment and correspond. They are “mailto:” links with appropriate properties which bring up outlook with subject tag and subject to the correspond/comment email address of the associated queue. To my team could easily outlook to reply and comment.
Some of my colleagues did not create their signature according to our internal manuals, and just copied it from others and that caused extra table.
In addition when we faced with this issue, I analyzed all the logs and found that this happed from other sources as well. Some of them were spam (which their format are usually weird) and others by few of our customers …