#52752 closed enhancement (wontfix)
trac: send fewer emails when replacing an attachment
Reported by: | RJVB (René Bertin) | Owned by: | admin@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | server/hosting | Version: | |
Keywords: | upstream | Cc: | |
Port: |
Description
The current trac version sends out 2 emails each time you replace an attachment with a new version. I'm not even sure there's much point in sending an email if an attachment is deleted but there certainly isn't if it's being replaced (and the new version also triggers an email alert).
It would be even better if the attachment page had a comment box, so one can update the attachments and describe the new state from a single page. Less clicking, page loading, and an up to 3x reduction in the number of alerts sent. (FWIW, KDE's bug tracker has this feature, in addition to the per-attachment description that trac also has.)
Change History (8)
comment:1 Changed 8 years ago by ryandesign (Ryan Carsten Schmidt)
Component: | website → server/hosting |
---|---|
Owner: | changed from jmpp@… to admin@… |
Status: | new → assigned |
comment:2 Changed 8 years ago by larryv (Lawrence Velázquez)
Summary: | trac chattyness → trac: send fewer emails when replacing an attachment |
---|
comment:3 Changed 8 years ago by larryv (Lawrence Velázquez)
Replying to RJVB:
The current trac version sends out 2 emails each time you replace an attachment with a new version. I'm not even sure there's much point in sending an email if an attachment is deleted but there certainly isn't if it's being replaced (and the new version also triggers an email alert).
At a glance, it doesn’t look like Trac can be configured that granularly.
comment:4 Changed 8 years ago by raimue (Rainer Müller)
Uploading an attachment that replaces an existing attachment is modeled by deleting the old version and adding the new one. Therefore you get two email notifications. The mails should indicate the action that triggered these notifications.
For your second request, please direct that to the Trac developers. KDE's bug tracker is Bugzilla.
comment:5 follow-up: 6 Changed 8 years ago by RJVB (René Bertin)
I know it was only yesterday that I thought previous trac versions auto-subscribed new participants to a ticket, but here I'm certain I never got 2 email when I replaced a ticket attachment. So that's a regression w.r.t. the previous version MacPorts used. I'm not even sure we got an email after adding each attachment. In itself that wouldn't surprise/annoy me. But given I've created quite a few tickets with more than 2-3 attachments I think I'd remember having to delete as many additional emails.
Is there a possibility to make sending notifications for attachment changes a per-user setting? I've lived just fine without them, and would prefer that over getting as many notifications as I'm getting ATM. I didn't see it in the current preferences pages, but it seems like such a common user setting that it surprises me a bit that trac wouldn't support it.
I wouldn't mind filing an upstream ticket for this, even if I'm not the one deploying the software. It'd help knowing how many other users would prefer to have more control over the notifications they get from this site!
(Rainer: I *think* I understood that particular part of why I'm getting 2 email notifications ;) )
comment:6 Changed 8 years ago by raimue (Rainer Müller)
Replying to RJVB:
[...] I'm certain I never got 2 email when I replaced a ticket attachment. So that's a regression w.r.t. the previous version MacPorts used.
The previous version was Trac 0.12 which did not send any notifications at all on attachment changes. Now we use Trac 1.0 which has this new feature.
comment:7 Changed 8 years ago by neverpanic (Clemens Lang)
Keywords: | upstream added |
---|---|
Resolution: | → wontfix |
Status: | assigned → closed |
This is a Trac upstream problem. We will not attempt to tackle this for our installation.
comment:8 Changed 8 years ago by RJVB (René Bertin)
In that case I will not attempt any longer to use the attachment replace function until this is fixed upstream and trickled downstream.
And FWIW: a bug/request ticket to change this upstream would really have to be filed by one of the trac.macports administrators to carry weight and not give any unwanted impressions about unhappy users.
Sounds like your complaint is with the developers of Trac, not MacPorts. We just use Trac. I'm not sure there's a way to configure things other than how they currently are.