Batching of email updates to prevent noise from repeated changes in a short period of time.

[michaelkaye]

Is your feature request related to a problem? Please describe.

I was using automated tools (eg, junit-xml plugin) to upload test case results to kiwi, and after using this, I ended up with what seemed an unbounded number of emails in my inbox as each test result uploaded triggered a change to the test run and so an email.

That underlying problem is reported here: https://github.com/kiwitcms/Kiwi/issues/3112

However, noise from repeated changes in a short time is a problem.

Describe the solution you'd like

Having an ability to not get these emails, in some way.

The ideal end result would be a single email containing all the changes that occurred; even if it's delayed by some minutes.

Describe alternatives you've considered

• Ability to disable email if a test plan or test run is marked "automated" (but this situation could occur for other sets of close updates even from the UI or API, so isn't a complete solution)
• Create a delayed queue of outbound notifications for each given database entity, such that at most one email about a given test run is sent every ~5min, containing a summary of changes

I envisage instead of generating individual diffs and passing them to be emailed in real time; instead a queue of "database entities that have been updated" should be formed, with some method of collapsing duplicate changes into a single entry.

After any entry times out (eg, 5min after the first change was made) a complete diff for the last 5min is generated and emailed. I think the database format contains enough audit information to be able to generate these; but I'm not sure.

In my use case that would collapse the 130 stop_time changes into one; if there was repeated editing of a test plan in the UI (eg, change title, change comment, change owner) in three updates, instead there would be one update with three changes.

Additional context

[atodorov]

FTR there is https://github.com/kiwitcms/Kiwi/issues/1398 which is about refactoring the email notification system and making it more granular which isn't directly related to this particular request.

However in terms of batching that may not be possible. Notifications are triggered via events (what Django calls post_update signals) and handled via callbacks. They are completely isolated from one another and as far as I've seen there's no mechanism to bundle them together.

Fixing the underlying issue and grouping changes when we're aware of them would help alleviate the problem here but I don't think it can be completely solved in the desired way.