[Rt-commit] rt branch, 4.2/improve-message-rfc822-handling, created. rt-4.2.1-45-g8591e51

[Alex Vandiver]

The branch, 4.2/improve-message-rfc822-handling has been created
        at  8591e51b928cbdd91f3826eb346d7f830c766f68 (commit)

- Log -----------------------------------------------------------------
commit 4f651e811ffaa105f6359431aa0b8eb868588540
Author: Kevin Falcone <falcone at bestpractical.com>
Date:   Wed Apr 21 16:10:43 2010 -0400

    RT::I18N::IsTextualContentType thinks message/rfc822 parts have content

diff --git a/lib/RT/Transaction.pm b/lib/RT/Transaction.pm
index 3b17319..3c9453e 100644
--- a/lib/RT/Transaction.pm
+++ b/lib/RT/Transaction.pm
@@ -509,7 +509,7 @@ sub ContentObj {
     return undef unless ($Attachment);
 
     # If it's a textual part, just return the body.
-    if ( RT::I18N::IsTextualContentType($Attachment->ContentType) ) {
+    if ( _IsDisplayableTextualContentType($Attachment->ContentType) ) {
         return ($Attachment);
     }
 
@@ -538,7 +538,7 @@ sub ContentObj {
         # If that fails, return the first textual part which has some content.
         my $all_parts = $self->Attachments;
         while ( my $part = $all_parts->Next ) {
-            next unless RT::I18N::IsTextualContentType($part->ContentType)
+            next unless _IsDisplayableTextualContentType($part->ContentType)
                         && $part->Content;
             return $part;
         }
@@ -548,6 +548,18 @@ sub ContentObj {
     return (undef);
 }
 
+=head2 _IsDisplayableTextualContentType
+
+We may need to pull this out to another module later, but for now, this
+is better than RT::I18N::IsTextualContentType because that believes that
+a message/rfc822 email is displayable, despite it having no content
+
+=cut
+
+sub _IsDisplayableTextualContentType {
+    my $type = shift;
+    ($type =~ m{^text/(?:plain|html)\b}i) ? 1 : 0;
+}
 
 
 =head2 Subject

commit 06ed4b6799dbd816128eafa041e42a07cee6aa74
Author: Kevin Falcone <falcone at bestpractical.com>
Date:   Wed Apr 21 16:13:35 2010 -0400

    Actually recurse into message/rfc822 parts looking for content
    
    We want to become better about recursing into multipart/ too, but
    this is better than the previous RT behavior which simply returned
    blank content

diff --git a/lib/RT/Transaction.pm b/lib/RT/Transaction.pm
index 3c9453e..db5b9ea 100644
--- a/lib/RT/Transaction.pm
+++ b/lib/RT/Transaction.pm
@@ -508,6 +508,34 @@ sub ContentObj {
 
     return undef unless ($Attachment);
 
+    my $Attachments = $self->Attachments;
+    while ( my $Attachment = $Attachments->Next ) {
+        if ( my $content = _FindPreferredContentObj( %args, Attachment => $Attachment ) ) {
+            return $content;
+        }
+    }
+
+    # If that fails, return the first top-level textual part which has some content.
+    # We probably really want this to become "recurse, looking for the other type of
+    # displayable".  For now, this maintains backcompat
+    my $all_parts = $self->Attachments;
+    while ( my $part = $all_parts->Next ) {
+        next unless _IsDisplayableTextualContentType($part->ContentType)
+        && $part->Content;
+        return $part;
+    }
+
+    return;
+}
+
+
+sub _FindPreferredContentObj {
+    my %args = @_;
+    my $Attachment = $args{Attachment};
+
+    # If we don't have any content, return undef now.
+    return undef unless $Attachment;
+
     # If it's a textual part, just return the body.
     if ( _IsDisplayableTextualContentType($Attachment->ContentType) ) {
         return ($Attachment);
@@ -519,7 +547,7 @@ sub ContentObj {
     elsif ( $Attachment->ContentType =~ m|^multipart/mixed|i ) {
         my $kids = $Attachment->Children;
         while (my $child = $kids->Next) {
-            my $ret =  $self->ContentObj(%args, Attachment => $child);
+            my $ret =  _FindPreferredContentObj(%args, Attachment => $child);
             return $ret if ($ret);
         }
     }
@@ -534,13 +562,17 @@ sub ContentObj {
                 return $first;
             }
         }
+    }
+
+    # If this is a message/rfc822 mail, we need to dig into it in order to find 
+    # the actual textual content
 
-        # If that fails, return the first textual part which has some content.
-        my $all_parts = $self->Attachments;
-        while ( my $part = $all_parts->Next ) {
-            next unless _IsDisplayableTextualContentType($part->ContentType)
-                        && $part->Content;
-            return $part;
+    elsif ( $Attachment->ContentType =~ '^message/rfc822' ) {
+        my $children = $Attachment->Children;
+        while ( my $child = $children->Next ) {
+            if ( my $content = _FindPreferredContentObj( %args, Attachment => $child ) ) {
+                return $content;
+            }
         }
     }
 

commit 8591e51b928cbdd91f3826eb346d7f830c766f68
Author: Kevin Falcone <falcone at bestpractical.com>
Date:   Wed Jun 1 20:38:47 2011 -0400

    Work with our new multipart handling
    
    As part of our outlook handling code, we started recursing into
    multipart/alternative.  However, if you were multipart/multipart or
    something else, and the code doesn't express a preference for text/plain
    vs text/html we had a bail out to start at the top again looking for
    textual.  Instead, we'll look at the children of this multipart for
    anything textual, since that seems to make more sense and leave the
    "Search for something textual from the top" for later in the code path.

diff --git a/lib/RT/Transaction.pm b/lib/RT/Transaction.pm
index db5b9ea..432a28b 100644
--- a/lib/RT/Transaction.pm
+++ b/lib/RT/Transaction.pm
@@ -561,6 +561,16 @@ sub _FindPreferredContentObj {
             if ( my $first = $plain_parts->First ) {
                 return $first;
             }
+        } else {
+            my $parts = $Attachment->Children;
+            $parts->LimitNotEmpty;
+
+            # If we actully found a part, return its content
+            while (my $part = $parts->Next) {
+                next unless _IsDisplayableTextualContentType($part->ContentType);
+                return $part;
+            }
+
         }
     }
 

-----------------------------------------------------------------------