Add e-mail preference for pool-change e-mails

[MarkMaldaba]

It would be really useful if there was an additional row in your user email preferences table that controls whether or not you get sent an e-mail when a bug is moved to a different pool (depending on your relationship to the bug, as for the other options in the table).

Currently, there is a lot of e-mail noise generated whenever bugs are moved around (at the end of every sprint), which can currently only be removed by disabling e-mails for when "any field not mentioned above changes", which is not what is wanted (most other fields we still want to receive alerts about).

I don't know if Bugzilla provides a way to add this option, but if so it would be a great addition to the tool.

[keto]

It is possible... But I'm not sure where this email noise comes from as I haven't noticed such. At least the pool modifications done via the planning view should not generate any bug mails.

[MarkMaldaba]

You're right, we don't get e-mail notifications from the planning view - this occurs when changing pool on the bug edit page, which is something we do a lot and which we rarely, if ever, want to get e-mails about.

However, it brings to light an interesting inconsistency in the way pool-changes are handled with regards e-mail alerts. Ideally, the system would be consistent, whichever method was used to change this field.

Probably the 'correct' way of working is that all changes end up triggering a potential e-mail, with the option about whether or not you receive e-mails relating to pool changes being configurable via the standard e-mail settings. (And I would recommend it defaults to 'off'.)

However, I'm aware that the AJAXy nature of the planning interface would make this pretty horrible in practice - you would be sent several e-mails for every drag-and-drop action, which is clearly unacceptable. Ideally, there would be some kind of 'commit' that triggered the e-mails when editing was complete (either an explicit 'commit' button, or some kind of time-delayed trigger that occurs if no further edits are made within X minutes). However, in practice, this may be unimplementable.

An alternative approach to consistency would be the opposite approach, i.e. that pool changes never get reported (they don't trigger e-mails ever, and they aren't reported in bug-change e-mails when they occur at the same time as other changes). I don't know whether Bugzilla provides a simple way of declaring a field to be 'uninteresting' and to remove it from alerts, or whether this would require a more complex solution (if, indeed, it is possible at all), but for our use-case - where we never really want to be alerted about pool changes - this approach would be quite acceptable (though for a more general user-base, the first option gives more flexibility).

Anyway - a bit of a brain-dump there! The main issue from our point of view is to not get e-mails when a bug is edited and all that is changed is the pool.