Right now the sending of 'nosy' messages is handled by
IssueClass.nosymessage. This messages determines whom to send a given
message to, based on the issue's 'nosy' property.

Users may want to modify the way this message is sent out. For example,
they may want to send multiple mails, where addresses are grouped by
certain criteria (to hide customers from each other, say).

Is there any reason this code could not be moved into the nosyreaction
class itself (or a baseclass, if it is used elsewhere, too) ? That would
allow it to be customized.

On 30/05/2009, at 1:42 AM, Stefan Seefeld wrote:
> Right now the sending of 'nosy' messages is handled by
> IssueClass.nosymessage. This messages determines whom to send a given
> message to, based on the issue's 'nosy' property.
> ...
> Is there any reason this code could not be moved into the nosyreaction
> class itself (or a baseclass, if it is used elsewhere, too) ? That  
> would
> allow it to be customized.

It was moved into the roundup core to facilitate bug fixing without  
requiring users to reinstall their detectors every release.

Richard Jones wrote:

>> Is there any reason this code could not be moved into the nosyreaction
>> class itself (or a baseclass, if it is used elsewhere, too) ? That  
>> would
>> allow it to be customized.
> 
> It was moved into the roundup core to facilitate bug fixing without  
> requiring users to reinstall their detectors every release.

I don't quite understand what you are saying. Why would users have to 
reinstall anything for 'every release', if this was in a detector ?

Thanks,
	Stefan

On 01/06/2009, at 10:11 AM, Stefan Seefeld wrote:
> Richard Jones wrote:
>>> Is there any reason this code could not be moved into the  
>>> nosyreaction
>>> class itself (or a baseclass, if it is used elsewhere, too) ? That
>>> would
>>> allow it to be customized.
>>
>> It was moved into the roundup core to facilitate bug fixing without
>> requiring users to reinstall their detectors every release.
>
> I don't quite understand what you are saying. Why would users have to
> reinstall anything for 'every release', if this was in a detector ?

Back in the bad old days this actually was an issue. There would be a  
bug fixed in the nosy reactor code, and everyone would have to update  
their trackers' copies of the detectors to fix the bug, rather than  
just upgrade the roundup lib install. "every release" was an  
unfortunate overstatement. Obviously they'd only have to update their  
detectors if there was a bug fixed in there (though that means of  
course that they have to keep a close eye on the CHANGES / upgrading  
file and we'd have to make sure we document the need to update  
detectors...)

OK, I see. Now, I totally understand that there is no way to move the 
code out of the IssueClass class (as that would break backward 
compatibility).

However, users may want to rewrite the IssueClass.nosymessage algorithm 
in a custom reactor, only using IssueClass.send_message(), right ?

Thanks,
		Stefan

I am closing this. I think yes, the nosymessage/send_message can be
refactored to allow detector writers a better API to control things.

I think there is a request to do that, so I am marking this a duplicate.