Question

Problem:

1. Alice mails a support question to Fogbugz, Bob, Carol and Dick. Case #500 is created. Alice gets an email that case #500 is created.
2. Not having a FogBugz account, Bob does a Reply-All to Alice, Fogbugz, Carol, and Dick. Case #501 is created. Bob gets an email that case #501 is created and is confused.
3. Dick has a FogBugz account, but he wants to reply to Bob about scheduling a shipment to Alice and he doesn't think its being tracked by FogBugz because he sees no case number, so he also makes a Reply-All to Bob, Alice, Fogbugz, and Carol. Case #502 is created. Dick gets an email that case #502 is created and shrugs it off.
4. Carol should know better, but does a Reply-All to Dick, Bob, Alice, and Fogbugz anyway. Case #503 is created. Carol gets an email that case #503 is created and then smacks her forehead.
5. Ellen is a programmer with a FogBugz account and gets emails each time new cases appear from the Internet. She gets case #500, adjusts the details, and sets a date for the bugfix. She then marks cases #501, #502, and #503 as duplicates. She would like to email Bob, Carol, and Dick to remind them not to cc the FogBugz account on Reply-Alls, but the problem really lies with Alice, who started the mess. But Alice is a customer who could have never forseen the train of events she was about to kick off because all email addresses are supposed to be equal. And Bob, Carol, and Dick are pretty busy themselves and don't have time to pick through and verify every member of a distribution list.

Solution: Ellen thinks that FogBugz should start storing the Message-ID: from the header of email that creates a new case. Should a new email come in that has no case number in the Subject: line but does have a References: line that contains a Message-ID from an existing case, FogBugz should attach this email to the existing case instead of creating a new one. Just to be safe, should more than one case match in the References: line (vanishingly rare), a new case could be created (although Ellen thinks it would also be acceptable to match the first mentioned Message-ID in the References header line).

Note: This situation happens several times a week here because of how support used to work with a shared mailbox (cc's were encouraged). It is a pretty annoying workflow disruption.

Case FC1857808

Answer 1

Thanks for the detailed workflow and suggested solution, Todd!

This particular feature/workflow is already on our books as something to evaluate, so I've added the associated case to your question (the little kiwi icon) so we'll know to update this question if/when the status of our internal case for this changes.

Answer 2

This is still a serious problem. Now our users are emailing issues into Fogbugz a lot, more than half of the outstanding cases are this type of duplicate. This is very messy and time-consuming to deal with.

Has it been done yet? btw, I regard this as a bug to fix, not a feature to evaluate.

Answer 3

+1 This is a problem for us as well, since all our customers email with a wide cc list.

There are many examples of exactly how this can be implemented, primarily using the IMAP THREAD Extension Protocol (RFC 5256).

http://tools.ietf.org/search/rfc5256

The most important section of the document with regard to FogBugz linking emails would probably be this:

Note: "Message ID" in the following description refers to a
        normalized form of the msg-id in [RFC2822].  The actual text
        in RFC 2822 may use quoting, resulting in multiple ways of
        expressing the same Message ID.  Implementations of the
        REFERENCES threading algorithm MUST normalize any msg-id in
        order to avoid false non-matches due to differences in
        quoting.

        For example, the msg-id
           <"01KF8JCEOCBS0045PS"@xxx.yyy.com>
        and the msg-id
           <01KF8JCEOCBS0045PS@xxx.yyy.com>
        MUST be interpreted as being the same Message ID.

     The references used for reconstructing a message's ancestry are
     found using the following rules:

        If a message contains a References header line, then use the
        Message IDs in the References header line as the references.

        If a message does not contain a References header line, or
        the References header line does not contain any valid
        Message IDs, then use the first (if any) valid Message ID
        found in the In-Reply-To header line as the only reference
        (parent) for this message.

           Note: Although [RFC2822] permits multiple Message IDs in
           the In-Reply-To header, in actual practice this
           discipline has not been followed.  For example,
           In-Reply-To headers have been observed with message
           addresses after the Message ID, and there are no good
           heuristics for software to determine the difference.
           This is not a problem with the References header,
           however.

        If a message does not contain an In-Reply-To header line, or
        the In-Reply-To header line does not contain a valid Message
        ID, then the message does not have any references (NIL).

     A message is considered to be a reply or forward if the base
     subject extraction rules, applied to the original subject,
     remove any of the following: a subj-refwd, a "(fwd)" subj-
     trailer, or a subj-fwd-hdr and subj-fwd-trl.

I can see from the FogBugz 'view source' option with incoming emails that the header's are all available, with correctly matching 'references: ' and 'in-reply-to: ' to 'message-id: ' headers.

Please add this feature!

Answer 4

This is an annoying bug, not a feature. I am at the mercy of outside correspondents who may change the subject line or replay all as described above.

Right now I am looking at three consecutive cases created by the same e-mail thread. It would be nice to simply be able to move or merge each of the improperly categorized messages into the pre-existing case.

Answer 5

I agree that this is a critical fix and should not be considered a "feature" as we are finding it takes considerable effort in FogBugz to manage the multiple (on occasions over 30) emails which result simply from the original submitter cc'ing people on the initial email.

Please implement asap.

Answer 6

+1 This is our biggest issue with fogbugz.

Answer 7

After a year and a half, are we wasting our time with FogBugz on this question?