Edgewall Software
Modify

Opened 13 years ago

Last modified 6 months ago

#9971 new defect

cannot unsubscribe from bug, no way, no how

Reported by: jidanni@… Owned by:
Priority: normal Milestone: next-stable-1.6.x
Component: notification Version: 0.12
Severity: normal Keywords: unsubscribe
Cc: Emmanuel Blot Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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.

Attachments (0)

Change History (19)

comment:1 by Remy Blank, 13 years ago

Resolution: duplicate
Status: newclosed

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.

comment:2 by Christian Boos, 13 years ago

Cc: Emmanuel Blot added

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? :-)

comment:3 by jidanni@…, 13 years ago

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

comment:4 by Christian Boos, 13 years ago

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.

in reply to:  4 ; comment:5 by Christian Boos, 13 years ago

Keywords: unsubscribe added
Milestone: next-minor-0.12.x
Resolution: duplicate
Status: closedreopened

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.

comment:6 by Christian Boos, 13 years ago

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

in reply to:  5 ; comment:7 by anonymous, 13 years ago

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.

in reply to:  7 ; comment:8 by anonymous, 13 years ago

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.

comment:9 by lkraav <leho@…>, 12 years ago

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.

in reply to:  9 comment:10 by Remy Blank, 12 years ago

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.

comment:11 by Ryan J Ollos, 9 years ago

Milestone: next-minor-0.12.xnext-stable-1.0.x

comment:12 by Ryan J Ollos, 9 years ago

Status: reopenednew

in reply to:  8 comment:13 by samuel.lelievre@…, 8 years ago

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.

comment:14 by anonymous, 8 years ago

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

in reply to:  14 comment:15 by slelievre, 8 years ago

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.

comment:16 by Ryan J Ollos, 7 years ago

Milestone: next-stable-1.0.xnext-stable-1.2.x

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.

comment:17 by Ryan J Ollos, 4 years ago

Milestone: next-stable-1.2.xnext-stable-1.4.x

comment:18 by jidanni@…, 2 years ago

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.

comment:19 by Ryan J Ollos, 6 months ago

Milestone: next-stable-1.4.xnext-stable-1.6.x

Milestone renamed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.