#82 E-mails and bugs - mark incoming as new, followup, ignore

[Jochen Jonckheere]

For the moment there is a possibility to read a mailbox
and add the mails as a bug in BugTracker.

But wouldn't it be better if a mailbox was read. And all
the mails where shown in a list and then have the
possibility to:

- create a new bug from a mailmessage
- add the mail to a bug (followups)
- or just ignore the mail

This way it is possible to have a full history of a bug.

[Corey Trager]

Logged In: YES
user_id=645778

I understand the problem you are trying to solve, and I like
your idea.

I don't like the idea of having to manually act on each
incoming email.

Perhaps another approach would be the ability to merge bugs
after they have been added. After the fact,

- doing nothing
- merging
- deleting

corresonds to your

-- create
-- add followup
-- ignore

Maybe another approach would be the ability to merge the
histories of a couple bugs?

[Jochen Jonckheere]

Logged In: YES
user_id=967755

The problem I see with your approach is that there will still be
some manual work.

Every e-mail is a bug. E-mails that are not a bug will have to
be deleted (normally work of an admin). Followups don't need
a new bug number and they will get it, in the proposed
approach.

My biggest problem was that a lot of people overload our
support with the lastest jokes and nonsence.

In the end there is always manual work. There is no way
around it.

Merging bugs is indeed an other solution or an extra that can
be added.

[Corey Trager]

Logged In: YES
user_id=645778

Regarding "people overload our support with the latest jokes..."

It sounds like for that specific problem, something like a
spam filter would be helpful. Would something like a spam
filter help?

The latest release of btnet includes a little filter that
says ignore any emails if the subject line contains a
specified string. It's all I happened to need for my
real job - there was just this one specific type of email we
wanted to filter out.

It probably wouldn't be that hard to add more filtering
ability. If you were to do it, I could incorporate your
changes back into the codebase. Only the file pop3main.cs
needs to be changed, around these lines:

        if \(SubjectMustContain \!= "" &&

subject.IndexOf(SubjectMustContain) < 0)
{
write_line("skipping because subject does not contain: "
+ SubjectMustContain);
continue;
}

        if \(SubjectCannotContain \!= "" &&

subject.IndexOf(SubjectCannotContain) >= 0)
{
write_line("skipping because subject cannot contain: " +
SubjectCannotContain);
continue;
}

[Corey Trager]

Logged In: YES
user_id=645778

I do like your idea. But our work situations are
different. At my real job, almost all of the incoming
emails should be new bugs and we have very few cases where
there are followups (Remember, if you send an outgoing
email from btnet, and the receiver responds, the little
bugid cookie in the subject line will allow the response to
be posted as a comment back to the original bug.).

So, your solution would mean more manual work for my
situation, but less for yours, whereas my solution means
more manual work for your situation and less for mine.

Of course it would be nice if btnet could be configurable to
work both ways. It would probably have to evolve into
something like a normal email client where various rules
determine whether an email is deleted, or filed away into a
special folder. So the btnet rules would be something like:

if email [subject/body/from address] [does/does not] match
[specified pattern] take the following action: [new
bug/delete/put in review queue]

Then the review queue would work as you propose.

[Jochen Jonckheere]

Logged In: YES
user_id=967755

What you say is correct.
The program will never be the optimal solution for all
situations.

You are correct when you say that an e-mail client with filter-
functions would be the best solution. But one of the things I
like in Bugtracker is it simplicity. More options can make it
more difficult to use and adminster.

Maybe the easiest solution would be that there is a possibility
to either let all things go as it is now or use a small e-
mailclient.

If I find the time, or better get the time (at work) to program
a small e-mailclient. Or maybe I can use some opensource
code, I will send it to you and you can still decide what to do.