Unmuting a bug's notifications should restore your previous direct subscription

[Gary Poster]

Muting a bug is done by setting a particular notification level on a subscription. This is unfortunate, because it means that, when a user unmutes, we have no idea whether the user was directly subscribed before, and if so, what level the user's subscription was.

We work around this by making the unmute UI ask the user whether they want to subscribe or not. This is making the best of a bad situation. It still leads to confusion, as evidenced in bug 770345 and bug 770342.

The proper fix, IMO, would be to have a BugMute table that has columns for a person and a bug. The combination must be unique. The presence of a record in the table for a given person and a given bug means that the bug is muted. Removing the record removes the mute, revealing the previous state. Unfortunately, I am afraid that doing this would be a very large refactoring.

A hack fix that would involve less refactoring would be to have a MutedBugSubscription table. Whenever you mute, if you already have a subscription, a record is made of the previous subscription: the person, the bug, and the level. When you unmute, the code looks to see if there is a row for the person and the bug in the MutedBugSubscription table. If there is, the previous level is reinstated on the subscription; and if not, the subscription is deleted. In both cases, the row in the MutedBugSubscription table is then deleted. I think this could be a significantly smaller refactoring.

I am triaging this low, though if we could get a fix in, it would be a big win for simplicity. I'm tempted to try the hack fix.

[Benji York (benji)]

Per email discussion I'm moving this to High importance.

[Jonathan Lange (jml)]

I've sort of lost track of the email discussion, but I agree with the bump in priority.

[Launchpad QA Bot (lpqabot)]

Fixed in db-stable r10561 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-stable/revision/10561>.

[Launchpad QA Bot (lpqabot)]

r10563 in db-stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-stable/revision/10563) is part of this bug's fix.

[Launchpad QA Bot (lpqabot)]

r10582 in db-stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-stable/revision/10582) is part of this bug's fix.

[Launchpad QA Bot (lpqabot)]

Fixed in db-stable r10583 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-stable/revision/10583>.

[Launchpad QA Bot (lpqabot)]

r10585 in db-stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-stable/revision/10585) is part of this bug's fix.

[Данило Шеган (danilo)]

This is roughly ok, though I did find a few problems:
 - "Unmute" links keeps pointing to "+subscribe" instead of "+mute" (+mute page was changed to support both muting/unmuting, and doesn't redirect to +subscribe when bug mail is muted anymore); this means that people will be sent to the wrong page if they have no JS
 - When there is a mute on a bug, but no subscription, clicking on "Subscribe" fails to pop-up the window; also, going to +subscribe page renders an empty form which doesn't work in that case (this two are likely related)
 - When one tries to "Subscribe" originally (or unmute when they have an old subscription, or unsubscribe yourself), subscription overlay pop-up stays loaded when you click on check-mark to apply the action even though the action succeeds; this is especially bad if there's an error since then the error pop-up is below the subscription overlay

Some of this might be due to the split of the subscription actions and subscribers list into separate "portlets".

[Данило Шеган (danilo)]

FWIW, this is on Epiphany, I'll have to recheck in other browser.