Hi all, On the topic of bug 772763, here's my summary.
У чет, 05. 05 2011. у 14:25 +0200, Danilo Šegan пише: > У уто, 03. 05 2011. у 14:56 -0400, Francis J. Lacoste пише: > > > Jono and I are tempted to say that we should try to fix the 'Unmuting a > > bug's > > notifications should restore your previous direct subscription ' bug in > > those > > two weeks. If that's something bigger than that, let's not bother. I don't > > think that not being able to deploy this at the end of the two weeks is a > > big > > deal. If we have a fix that will be rolled-out two weeks later, that's good > > enough. > > I'll look into how much effort this'd really take. Depending on that, I > might pursue it. Looking into it, it's not too complex. I should have the very basic functionality done tomorrow, but cleaning up the "NOTHING" level of subscriptions will take a bit more time, just like making sure UI interaction is clean and consistent will. This is how I see it: 1. Branch to introduce BugMute table and switch Bug mute/unmute methods to use it[*], and change one of getRecipientFilterData/construct_email_notifications to ignore recipients which are muting bug mail; the latter part of this still needs doing and testing. It turns out this is not overly complex because NOTHING level works "by default": it mutes your subscription because it changes the level to a lower one which nothing looks at when sending notifications. Direct subscriptions take precedence over assignee/implicit supervisor subscriptions. And they probably take precedence over structural ones, but I haven't checked that yet. Or well, not work: it doesn't work for team subscriptions in my testing. We took that this worked in good faith, but it doesn't. I spent most of my time trying to figure out how is muting a direct team subscription working, becoming convinced it's not, and then confirming it with a test. As a side effect of the change, we'll fix this as well (and be certain that no emails go out, because we'll be stopping them right before they fly out). 2. Branch to get rid of all BugSubscription.bug_notification_level == NOTHING usage 3. Branch to get rid of all BugSubscriptionFilter.bug_notification_level == NOTHING usage (not much of these), and removal of the NOTHING value from the BugNotificationLevel enum 4. Make sure UI flows nicely: i.e. when a subscription is unmuted, UI restores to a state to reflect that (since the JS keeps the subscription state pre-loaded, we might need to make sure it's there even if a subscription was muted when the page was initially loaded); also, "Unmute" perhaps needs not be a pop-up dialog anymore, but that's up for further discussion; interaction with the "Edit subscription" link gets trickier as well 1-3 are suitably easy, and I believe they can be finished in three days of work. I believe 2-3 need to be done so we are certain we haven't missed anything. 4 is a bit complex considering we are breaking some of the core assumptions of the model, and I wouldn't even try to give an estimate considering we are not set on what we want to do exactly. Choosing a simpler plan Gary proposed would not have helped this, because we'd still have to think about exactly the same problems. Cheers, Danilo [*] I am also changing the return value of mute() method to be a BugMute record: this means an incompatible API change, but it was exported as a write operation with no annotation for the return value, so I believe it doesn't matter. -- Mailing list: https://launchpad.net/~yellow Post to : [email protected] Unsubscribe : https://launchpad.net/~yellow More help : https://help.launchpad.net/ListHelp
