[rt-devel] Using MessageId field in Attachments table

[Eric Berggren]

This was hinted at by Bruce Campbell, and something that I've enjoyed
with in-house ticket systems, whereby the system can track e-mail articles
by Message-Id, upon failing locating a suitable Subject: or pseudo-header
RT- tag.  It's another way to stem having to roll tickets together and
such whenever the Subject: line gets munged or a new one created.  Some
mailers (Outlook) apparently don't do In-Reply-To: or preserve other headers,
and the same users who compose new e-mails rather than reply will still leave
one with the same issues, but this was something I was willing to look into
in my spare time.

As been pointed out, and observed myself, the MessageId field in the
Attachments table is available but currently unused. Am I correct in
assuming this is to eventually hold the id of incoming/outgoing
attachments/articles ?

For starters, I would add the following code segments into Attachment.pm :

        my $MessageId = $Attachment->head->get('message-id',0);
        defined($MessageId) or $MessageId = '';
        chomp($MessageId);

        $id = $self->SUPER::Create(TransactionId => $args{'TransactionId'},
                                   .....
                                   MessageId => $MessageId,
                                   Headers => $Attachment->head->as_string,
                                   Subject => $Subject,
                                   .....
                                  );

Then update  ParseTicketId()  called by rt-mailgate to include the
In-Reply-To:  field to search on in the event the Subject: header isn't
revealing. Any linking or combining functions would still work,
however, there doesn't appear to be any linkage from the attachments
back to the ticket. What associates these together ? A subsequent search
through that table looking for the particular attachment is needed to
get the TicketId.

Seems pretty straight-forward. Is there a catch buried in any of this ?
Was someone else working on this or been discussed previously ?


thanks,
-eric
--
Fujitsu Processor Technologies, Inc.
 (Lawrence System Integration, Inc.)