[rt-users] bug in HTML::FormatText::WithLinks::AndTables stops scrips working

2013-11-30 Thread Payam Poursaied
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:
https://rt.cpan.org/Public/Bug/Display.html?id=87457 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

 



Re: [rt-users] bug in HTML::FormatText::WithLinks::AndTables stops scrips working

2013-12-02 Thread Alex Vandiver
On Sat, 2013-11-30 at 16:59 +0100, Payam Poursaied wrote:
> 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



Re: [rt-users] bug in HTML::FormatText::WithLinks::AndTables stops scrips working

2013-12-03 Thread Payam Poursaied


> -Original Message-
> From: rt-users-boun...@lists.bestpractical.com [mailto:rt-users-
> 
> On Sat, 2013-11-30 at 16:59 +0100, Payam Poursaied wrote:
> > 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