On Fri, Oct 26, 2012 at 1:41 AM, Jure Žitnik <[email protected]> wrote:
> I think we need a consistent 'notification strategy' which is basically > deciding whether changes to structures related to tickets (products, > milestones...) actually result in ticket notifications or not. > This has been on my mind while working on some ticket, particular: http://trac.edgewall.org/ticket/4582#comment:6 I've been thinking that I might open a dedicated ticket in the Trac core after #4582 and #5658 are resolved to deal with the inconsistencies of when notifications are sent. > If we choose that the change of related structure actually triggers ticket > change we should keep in mind that even if we optimize the actual structure > update, we'd still have to do ticket change notifications for all related > tickets (which would result in huge database queries to fetch all affected > tickets anyway). > I need to look more closely at the implementation to say for certain that we don't need to be concerned about this, but I think that BatchNotifyEmail (1) exists to deal with this situation, as I've utilized in (2) by just following standard patterns seen in the Trac core. The AnnouncerPlugin doesn't yet support batch notifications as far as I know, but I haven't tested it out with Trac 1.0 in which the BatchNotifyEmail class was added. (1) http://trac.edgewall.org/browser/trunk/trac/ticket/notification.py#L444 (2) http://trac.edgewall.org/attachment/ticket/5658/t5658-r11413-1.patch
