Right now Bugmail.pm is a series of subroutines that deliver mail in a very complex fashion. I envision instead three objects: Bugzilla::ChangeSet -- An object that desctibes what has changed about a bug in a given change. Bugzilla::Mailer -- An object that takes a ChangeSet and sends a bunch of mail. Bugzilla::BugMail -- An individual bug email, sent to a single user. Generated by Bugzilla::Mailer.

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

I'ld like to see this happen for 4.0. Taking.

In Bug 544026, I ask for the ability to send an email for a non-specific change to a bug. This would be similar to calling Mailer() with a pre-determined ChangeSet but wanting a custom message to be used. The use case is writing an extension that will send emails when a bug refers to another bug. The referred-to-bug would have a comment-type email sent containing the contents of the referring bug's comment. Right now, getting the list of recipients out is impossible, short of re-writing Send().

I have a problem that is similar in nature - please let me know if I should file a separate bug. I too think that Bugmail needs a refactoring, especially the send() function. I would really like to see a separation of the recipients logic from the calling of sendMail(). This would be useful for developers who wish to write extensions concerning Bugmail. They could call Bugzilla::Bugmail::getRecipients() for example, and just get a hash of the supposed recipients - without actually sending any e-mails. I would be interested in helping write a patch if Emmanuel Seyman is no longer working on it.

There has been no activity from manu for the last 3 years, so you can safely start working on this bug. :)

However, note that the refactoring that should be done is the refactoring in comment 0, which will help make any other refactorings simpler.

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.