Patch query - single email per bug
kevin.benton at amd.com
Wed Dec 1 21:36:22 UTC 2004
The way the patch works here is off the @sentlist as built in
NewProcessOnePerson. What was done was basically to take the call to
sendmail out of this routine, and then add a call to SendMail() near the
end of ProcessOneBug().
>From what I'm hearing you say, one bug can have a number of different
email output types. My code doesn't currently account for that,
however, I can make an adjustment to cover that type of situation.
Here's how I would overcome that situation: During the build of email
recipients, a list of recipients would be created with each unique email
to go out. Uniqueness would be determined by getting an MD5sum of the
outbound text excluding the recipient list.
When the MD5's match, the email recipient would just get added to the
existing recipient list. If the outgoing text were unique, a new entry
in the hash would be created with the MD5 as the key.
'body'=>$bodystr /* message body */,
'subject'=>$subject /* message subject */}
Then, when SendMail() actually goes to sending the mail, it just steps
through the hash.
Of course, this could easily be done in a class. As I see it, the
methodology I am thinking of would still remain the same. :)
Thank you! More feedback?
On Wed, 2004-12-01 at 13:49, Gervase Markham wrote:
> J. Paul Reed wrote:
> > If you can resolve the fact that you'd have to send email to classes of
> > people (owner, all CC list, etc.), then it should be an acceptable
> > optimization.
> What about insidergroup? If a comment is marked as insidergroup, and
> other changes are made at the same time, half the CC list need one email
> and half need the other.
> It might be possible to write a patch which works out all the possible
> parameters for an email, and amalgamates any which have exactly the same
> parameters - but there's a danger of it breaking every time email gets
> more customisable.
> To view or change your list settings, click here:
More information about the developers