ExtractCustomFieldValues with attachments

Roy_Sowa · July 29, 2008, 5:01pm

I am currently using RT 3.6.5 and ECFV 1.2.b3

I cannot get the extract to work if the MatchString is not in the first attachment.
I have been using ECFV for a while on basic standard type email tickets, but now I have the requirement
to extract the MatchString from an attachment.

It does not seem to matter if the ticket is created via GUI or email.
The simplest test being;

Create ticket using GUI with a description that has the MatchString … ( this works CF get populated)
Create ticket using GUI without any description and attach text file that contains MatchString … ( this works Cf gets populated)
Create ticket using GUI with general desc and attach text file with MatchString … ( this fails No CF populated )

Questions:
Does ExtractCustomFieldValues work with multi part messages if the matchstring is in the second attachment?

Where did I go wrong ?

I have read the list , and ContentObj is what is being used.
Any hints or guidance would be much appreciated.

Thanks in advance.

Roy

Jean-Sebastien_Moris · July 29, 2008, 5:30pm

The problem is with the FindMatch function. It only checks the first
attachment. I overhauled this perl module quite a bit. Here’s my version
attached. Diff this one to yours to see the differences.

js.On Tue, Jul 29, 2008 at 01:01:49PM -0400, Roy Sowa wrote:

I am currently using RT 3.6.5 and ECFV 1.2.b3

I cannot get the extract to work if the MatchString is not in the first attachment.
I have been using ECFV for a while on basic standard type email tickets, but now I have the requirement
to extract the MatchString from an attachment.

It does not seem to matter if the ticket is created via GUI or email.
The simplest test being;

Create ticket using GUI with a description that has the MatchString … ( this works CF get populated)

Create ticket using GUI without any description and attach text file that contains MatchString … ( this works Cf gets populated)

Create ticket using GUI with general desc and attach text file with MatchString … ( this fails No CF populated )

Questions:
Does ExtractCustomFieldValues work with multi part messages if the matchstring is in the second attachment?
Where did I go wrong ?
I have read the list , and ContentObj is what is being used.
Any hints or guidance would be much appreciated.

Thanks in advance.

Roy

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net

ExtractCustomFieldValues.pm (4.45 KB)

Roy_Sowa · July 29, 2008, 6:37pm

JS,
There was/is a big diff between the two , so I copied your version over to test…
Cleared the mason… stop/started the web and repeated my tests…
Works !!!
I will now go through the diffs and try an understand it all

Many thanks for your quick help   ( this list rocks )

Roy

Jean-Sebastien Morisset jsmoriss@mvlan.net 29/07/2008 1:30 pm >>>
The problem is with the FindMatch function. It only checks the first
attachment. I overhauled this perl module quite a bit. Here’s my version
attached. Diff this one to yours to see the differences.

js.On Tue, Jul 29, 2008 at 01:01:49PM -0400, Roy Sowa wrote:

I am currently using RT 3.6.5 and ECFV 1.2.b3

I cannot get the extract to work if the MatchString is not in the first attachment.
I have been using ECFV for a while on basic standard type email tickets, but now I have the requirement
to extract the MatchString from an attachment.

It does not seem to matter if the ticket is created via GUI or email.
The simplest test being;

Create ticket using GUI with a description that has the MatchString … ( this works CF get populated)

Create ticket using GUI without any description and attach text file that contains MatchString … ( this works Cf gets populated)

Create ticket using GUI with general desc and attach text file with MatchString … ( this fails No CF populated )

Questions:
Does ExtractCustomFieldValues work with multi part messages if the matchstring is in the second attachment?
Where did I go wrong ?
I have read the list , and ContentObj is what is being used.
Any hints or guidance would be much appreciated.

Thanks in advance.

Roy

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net

Roy_Sowa · July 29, 2008, 7:22pm

JS, I spoke too soon…
The issue now is that I extract fine from the attachment, but now if the matchstring is in the first attachment it is not found…
So I have put back the original file, and am back to not being able to extract from attachments …
So between the two files is the solution…
I want to extract the MatchString if it is in either.
Off to review the diffs and logic…but if anyone can help me out of the weeds

Jean-Sebastien Morisset jsmoriss@mvlan.net 29/07/2008 1:30 pm >>>
The problem is with the FindMatch function. It only checks the first
attachment. I overhauled this perl module quite a bit. Here’s my version
attached. Diff this one to yours to see the differences.

js.On Tue, Jul 29, 2008 at 01:01:49PM -0400, Roy Sowa wrote:

I am currently using RT 3.6.5 and ECFV 1.2.b3

I cannot get the extract to work if the MatchString is not in the first attachment.
I have been using ECFV for a while on basic standard type email tickets, but now I have the requirement
to extract the MatchString from an attachment.

It does not seem to matter if the ticket is created via GUI or email.
The simplest test being;

Create ticket using GUI with a description that has the MatchString … ( this works CF get populated)

Create ticket using GUI without any description and attach text file that contains MatchString … ( this works Cf gets populated)

Create ticket using GUI with general desc and attach text file with MatchString … ( this fails No CF populated )

Questions:
Does ExtractCustomFieldValues work with multi part messages if the matchstring is in the second attachment?
Where did I go wrong ?
I have read the list , and ContentObj is what is being used.
Any hints or guidance would be much appreciated.

Thanks in advance.

Roy

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net

Jean-Sebastien_Moris · July 29, 2008, 8:09pm

JS, I spoke too soon…
The issue now is that I extract fine from the attachment, but now if the matchstring is in the first attachment it is not found…

What’s the MIME Type of your first attachment?

Line #100 might be skipping the first attachment:

97          while (my $Message = $Attachments->Next) {
98                  $AttachNumber++;
99                  $RT::Logger->info("considering attachment #".$AttachNumber." of type ".$Message->ContentType);

100 next unless $Message->ContentType =~ m!^(text/plain|message|text$)!i;
101 next unless $Message->Content;

js.
Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net

Roy_Sowa · July 30, 2008, 11:52am

JS,
It is text/plain.
Your modified version of ECFV seems to handle looping through the attachments, but misses the initial first attachment,
The original ECFV handles the first attachment but in my case is not looping through any additional attachments to the transaction.
I will try and merge the two versions today ( they are very different )
Again thanks for your support and interest …

Jean-Sebastien Morisset jsmoriss@mvlan.net 29/07/2008 4:09 pm >>>

JS, I spoke too soon…
The issue now is that I extract fine from the attachment, but now if the matchstring is in the first attachment it is not found…

What’s the MIME Type of your first attachment?

Line #100 might be skipping the first attachment:

97          while (my $Message = $Attachments->Next) {
98                  $AttachNumber++;
99                  $RT::Logger->info("considering attachment #".$AttachNumber." of type ".$Message->ContentType);

100 next unless $Message->ContentType =~ m!^(text/plain|message|text$)!i;
101 next unless $Message->Content;

js.
Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net

Jean-Sebastien_Moris · July 30, 2008, 12:03pm

JS,
It is text/plain.
Your modified version of ECFV seems to handle looping through the attachments, but misses the initial first attachment,
The original ECFV handles the first attachment but in my case is not looping through any additional attachments to the transaction.
I will try and merge the two versions today ( they are very different )
Again thanks for your support and interest …

Hm. That doesn’t sound right. Turn on debugging in your syslog and check
the log. For example, in /etc/syslog.conf: *.debug /var/log/debug. Don’t
forget to do a touch /var/log/debug before re-starting the syslogd.

I’ve added quite a few RT::Logger msgs in the module, so check the
/var/log/debug file for something like:

Jul 29 16:57:32 localhost RT: considering attachment #1 of type multipart/alternative
Jul 29 16:57:32 localhost RT: considering attachment #2 of type text/plain
Jul 29 16:57:32 localhost RT: accepted attachment #2 for consideration
Jul 29 16:57:32 localhost RT: considering attachment #3 of type text/html

Don’t forget to either disable debug info after you’re finished, of
rotate that file daily – it can grow pretty big.

js.

Jean-Sebastien Morisset jsmoriss@mvlan.net 29/07/2008 4:09 pm >>>

JS, I spoke too soon…
The issue now is that I extract fine from the attachment, but now if the matchstring is in the first attachment it is not found…

What’s the MIME Type of your first attachment?

Line #100 might be skipping the first attachment:
97          while (my $Message = $Attachments->Next) {
98                  $AttachNumber++;
99                  $RT::Logger->info("considering attachment #".$AttachNumber." of type ".$Message->ContentType);
100 next unless $Message->ContentType =~ m!^(text/plain|message|text$)!i;
101 next unless $Message->Content;

js.

Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net

Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net