launchpad-reviewers team mailing list archive

[Steve Kowalik <stevenk@xxxxxxxxxx>]

The proposal to merge lp:~stevenk/launchpad/destroy-cause-unknownrecipienterror into lp:launchpad has been updated.

Description changed to:

When changing assignee, we want to filter it out of the "normal" notification mail that other subscribers recieve. To this end in the zope subscriber function receives a list of subscribers that will be notified by set difference using the two objects on the event. We then trawl through this list looking for the assignee so we can remove them.

So, this is fine. In the case that we only change the assignee, *or* all new subscribers are in the recipients list we build. Where this house of cards completely falls down is if we have a structural subscriber on a milestone with LIFECYCLE set. (LIFECYCLE subscribers only get notified on a new bug or a bug being closed.) When the assignee is changed and the milestone is set in *one action* using BugTask:+editstatus, we go through the list of new subscribers, and then raise an UnknownRecipientError because the structural subscriber isn't in the recipient list, and then OOPS.

Yay for layering violations. I've worked around this by checking if the person is in the recipients list first, and added a verbose comment to that effect.

I have also gone through test_bugtask.py and removed a bunch of excess whitespace to cause this branch to be a net LoC loss. Also, correct a thinko that I noticed.

For more details, see:
https://code.launchpad.net/~stevenk/launchpad/destroy-cause-unknownrecipienterror/+merge/125397
-- 
https://code.launchpad.net/~stevenk/launchpad/destroy-cause-unknownrecipienterror/+merge/125397
Your team Launchpad code reviewers is requested to review the proposed merge of lp:~stevenk/launchpad/destroy-cause-unknownrecipienterror into lp:launchpad.