Split off from issue2550574.

On Tue, May 15, 2012 at 12:53:34PM -0400, W. Trevor King wrote:
> I also agree that `newissuecopy.py' is important.  After reading the
> config comments:
> 
>   # The 'dispatcher' is a role that can get notified
>   # of new items to the database.
> 
> It seems to me that DISPATCHER_EMAIL should be notified of all new
> items, not just bounced messages as is currently hardcoded into
> Mailer.bounce_message.
> 
> I've attached a tweaked version of `newissuecopy.py' that implements
> this for all items.  I thing that a number of email-generating methods
> from IssueClass should actually be Item methods, so they can also be
> used on non-Issue nodes.  This would remove a lot of the duplicated
> code from my `newitemcopy.py'

On Wed, May 16, 2012 at 08:10:30AM +0000, Thomas Arendsen Hein wrote:
> We nearly always use newissuecopy.py to inform some users or a
> public mailing list about new issues (or in one case new merge
> entries), but not about everything.

My script notifies you about everything.

> DISPATCHER_EMAIL is the supervisor who wants to be notified about
> everything, so this is something different.

So it makes sense that I use DISPATCHER_EMAIL in my script.

> First step should be to revive the removed detectors. But yes,
> providing more flexibility with less code duplication would be nice,
> as would be the possibility to set the newissuecopy recipients in
> config.ini (without preventing configuration in newissuecopy.py
> itself of course).

I haven't addressed the code-duplication issue yet, since that would
require a more intrusive patch.  If people think this would be a good
direction to move in, I'm happy to add the Item methods.

On Wed, Aug 01, 2012 at 06:55:54PM +0000, Bernhard Reiter wrote:
> Trevor, can you open a new issue with your improvement please?  (As
> this issue is quite specific about restoring the old situation. I
> believe you are changing some of the conditions how this is used and
> I haven't fully thought it through.)

Here it is.