Optimize ticket attachment notifications

[aldeck]

I know the feature has been wanted for a long time and is really apreciated. However a slight enhancement might be needed to reduce to amount of notifications while still not missing anything.

1. When attaching a file at ticket creation (checking the "i have files to attach to this ticket") i should theoretically be possible to avoid the attachment notification without missing anything.
   

2. When attaching several files in series, use a time delay to check when the user stopped adding more files, and thus only notify after all files have been attached.
   

ps: 1 might be a variant of 2.

[nielx]

Replying to aldeck:

1. When attaching a file at ticket creation (checking the "i have files to attach to this ticket") i should theoretically be possible to avoid the attachment notification without missing anything.
   

2. When attaching several files in series, use a time delay to check when the user stopped adding more files, and thus only notify after all files have been attached.
   

ps: 1 might be a variant of 2.

My strong opinion is that any issue with too many notifications rather is a problem with filtering at the user's end than with us sending it.

Besides that, the features you are requesting are not very easy to implement in terms of how http works. Right now, the notifications are sent out within each request. What you name in #1, adding attachments is a second request, which does not know anything about the first request. The issue you name in #2 is even more difficult to solve, as it would mean that the emails should be solved in a different request.

Now there are possible solutions: for 1: It might be possible to add a hidden field to the 'add attachment' page after it is opened from a ticket creation in order to suppress sending the _first_ attachment notification. This would not help for any further notifications.

for 2: it is possible to make Trac send the emails after the attachments are five minutes old, but this means finding good criteria for determining a series of attachments. This would mean that in every request (so every page request at this website) there will be one or more database lookups in order to determine whether there should be a ticket attachment round. This will lead to increased loading times (and server load).

Now in my opinion, neither option are worth the hassle. I wonder how many attachment notifications we will save for 1, and whether people wish this to be the case, and for 2 both the resource cost as well as the cost for implementing and testing the feature far outweigh the advantages.

That is why I am now inclined to mark this ticket as 'invalid'. Feel free to write a patch or suggest another solution though.

[aldeck]

For 1), the "hidden field solution" sounds nice.

For 2), i understand it's not worth it if it's that much work :) What about adding the possibility to attach multiple files, or like in 1), add a "i have (yet) more file(s) to attach". That should be solvable with the 1) solution.

As for the motivations, i'm basically reading all trac notifications, even for area that don't concern me directly since sometimes a bug is misclassified when initially filed. I'm also interested in hot/high-activity tickets that i could provide testing for. And thus receiving 6 notifications for a series of screenshots adds some noise to the way i process those notifications and i don't see how i could filter that on my end.

Disclaimer: if it's not too much work (and if i'm not the only one wanting this) :)

[nielx]

ANOTHER TEST

[nielx]

We now use the standard AttachmentNotifiers from Trac 1.0.13. Any requested updates should be forwarded there.