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

Bug #772763 reported by Gary Poster on 2011-04-28
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Данило Шеган

Bug Description

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.

Related branches

Gary Poster (gary) on 2011-04-29
tags: added: story-better-bug-notification
removed: better-bug-notification
Benji York (benji) wrote :

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

Changed in launchpad:
importance: Low → High
Jonathan Lange (jml) wrote :

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

Changed in launchpad:
assignee: nobody → Данило Шеган (danilo)
status: Triaged → In Progress
Launchpad QA Bot (lpqabot) wrote :
tags: added: qa-needstesting
Changed in launchpad:
status: In Progress → Fix Committed
Launchpad QA Bot (lpqabot) wrote :
Changed in launchpad:
status: Fix Committed → In Progress
Launchpad QA Bot (lpqabot) wrote :
Changed in launchpad:
status: In Progress → Fix Committed
Launchpad QA Bot (lpqabot) wrote :
tags: added: qa-ok
removed: qa-needstesting

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".

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

William Grant (wgrant) on 2011-06-09
Changed in launchpad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers