cannot unsubscribe from bug, no way, no how

[jidanni@…]

As you can see in ​http://trac.transmissionbt.com/ticket/532#comment:75 not me, a mere user, nor him, an administrator, can unsubscribe me from that bug, no way, no how.

[Remy Blank]

Duplicate of #8677 and related to #6173.

The site owner might also want to have a look at the [notification] always_notify_updater in trac.ini.

[Christian Boos]

Excellent Remy! I wrote nearly the same message, but I would have referred to #6217 instead. This is a testimony to the broad range of refactoring tickets we have for the notification subsystem.

Manu, are you looking for a pet project for 2011? :-)

[jidanni@…]

In ​https://trac.transmissionbt.com/ticket/532#comment:86 he replies "I'm not sure what you want me to do with this information. "

[Christian Boos]

I'm not sure either what you're trying to achieve… you pointed to a known limitation of the Trac software. No, if they are happy with always_notify_updater = true and don't intend to change it, there's currently no way for updaters to avoid being notified. The reference to the various other tickets here are mentioning several ideas about how to overcome that limitation in future versions of Trac, and in fact it's strange you even ask again as I see you had already reported this problem in #9856 in the past. Creating more tickets about this will not help to make the problem go away, what is needed is someone willing to put some work in this notification subsystem or at least provide good patches.

[Christian Boos]

As an afterthought…

… or at least provide good patches.

For example, to address the specific problem reported here, one approach that could work is to retrieve from the ticket changes all explicit "removal from CC:" operations and from that build a list of people which should be removed from the final list of recipients. Not optimal, as you would have to first add yourself to the Cc: in case you're being notified because you're the reporter, the owner or an updater, but this would be simpler to implement than the deeper change implied by #8677.

[Christian Boos]

#9247 reported a case of "conflicting" settings that could also be solved if we allow to "force" unsubscription.

[anonymous]

Replying to cboos:

Not optimal, as you would have to first add yourself to the Cc: in case you're being notified because you're the reporter, the owner or an updater, but this would be simpler to implement than the deeper change implied by #8677.

I don't think it is not-optimal at all. You could just turn "always_notify_updater" into "always_cc_updater", with the effect that he would be automatically added to the list of CCs when the bug is created. Then he can very easily, and without any break in the UI, remove himself from that list.

[anonymous]

Replying to anonymous:

I don't think it is not-optimal at all. You could just turn "always_notify_updater" into "always_cc_updater", with the effect that he would be automatically added to the list of CCs when the bug is created. Then he can very easily, and without any break in the UI, remove himself from that list.

That would be better than what we've got now.

[lkraav <leho@…>]

this has recently popped up on ​django:#16763. cboos, this is the only ticket with "unsubscribe" keyword, should more be keyworded? for example #9856 #8677 #8637 #8311 #8287 #6306 #6173 #5356.

[Remy Blank]

Replying to lkraav <leho@…>:

cboos, this is the only ticket with "unsubscribe" keyword, should more be keyworded? for example #9856 #8677 #8637 #8311 #8287 #6306 #6173 #5356.

Please do so if you think it helps finding relevant tickets.

[samuel.lelievre@…]

Replying to anonymous:

Replying to anonymous:

I don't think it is not-optimal at all. You could just turn "always_notify_updater" into "always_cc_updater", with the effect that he would be automatically added to the list of CCs when the bug is created. Then he can very easily, and without any break in the UI, remove himself from that list.

That would be better than what we've got now.

Is this being implemented. It sounds like it would be an excellent solution to "always_cc_updater" instead of "always_notify_updater", thus letting anyone, whether updater or not, un-cc themselves freely.

[anonymous]

Is this even relevant anymore? Per default any user can now unsubscribe from any notifications in the preferences: wiki:1.1/TracNotification#SubscriberConfiguration

[slelievre]

Replying to anonymous:

Is this even relevant anymore? Per default any user can now unsubscribe from any notifications in the preferences: wiki:1.1/TracNotification#SubscriberConfiguration

I think it is still relevant.

A global preference to "always" or "never" notify me about trac tickets I edited is good, but I might want to unsubscribe from notifications about a particular trac ticket I edited and no longer care about, while keeping notifications on in general.

[Ryan J Ollos]

Moved ticket assigned to next-stable-1.0.x since maintenance of 1.0.x is coming to a close. Please move the ticket back if it's critical to fix on 1.0.x.

[jidanni@…]

On GitHub, one can unsubscribe from individual issues. On Trac, on can only unsubscribe from the entire site. Fine. That's exactly what I shall do.

[Ryan J Ollos]

Milestone renamed