Make the grouping of interleaved changes less time-sensitive

[Graham Binns]

At the moment BugActivity and comments are grouped together based on the time at which they occurred, with the requirement being that they occur at exactly the same time for them to be grouped together. Currently we can rely on this since things that should be grouped together (description, summary and tag changes; status, importance, milestone and assignee changes) will share a transaction time as they are submitted as part of the same form.

Once we move to an AJAX-driven bugs page, though, this is going to be come more problematic, since people will be able to edit two or three things separately on the same page. Whilst the user may perceive this to be one set of activity it will in fact be three different DB transactions, each of which will have a different transaction time, even if they're within milliseconds of each other. This will break the grouping and make the activity notifications cluttersome.

What should happen:

We should group activity and comments by time and person. We can be a bit looser with the time, then, since it doesn't really matter if we group two sets of actions carried out by the same person together. We can group together everything done by a person within five minutes (for example) of the first action by that person. If someone else makes another change in that time we can simply split that out into another set of actions. A new comment by any person essentially marks the start of a new block, so that comments are always separated, thus:

 1. Foo Bar adds a comment
 2. Foo Bar sets status
 3. Foo Bar changes description

Is one block of items, but:

 1. Foo Bar adds a comment
 2. Foo Bar sets status
 3. Foo Bar changes description
 4. No Priv sets importance
 5. Foo Bar adds a comment
 6. Foo Bar changes summary

Is three blocks of items, even if all of Foo Bar's actions take place within five minutes of each other. Each new comment starts a new block.

[Martin Pool (mbp)]

This sounds good.

At the moment you get the somewhat surprising behaviour that one logical change of setting the status and adding a comment generates one mail but two entries in the bug page.

[Gavin Panella (allenap)]

To give us the "loose" date/time grouping, we can use DateTimeFormatterAPI.approximatedate() as part of the grouping key (the other part being the person making the change).

[Graham Binns (gmb)]

2009/7/24 Gavin Panella <email address hidden>:
> To give us the "loose" date/time grouping, we can use
> DateTimeFormatterAPI.approximatedate() as part of the grouping key (the
> other part being the person making the change).

Comments are a hard boundary for grouping activity, too, so I think
that maybe just using approximatedate() might not be sufficient, since
we need to establish which activity goes with which comment. (Note
that I'm writing this off the top of my head and haven't looked at the
approximateddate() code).

[Gavin Panella (allenap)]

gmb wrote:
> Comments are a hard boundary for grouping activity, too, so I think
> that maybe just using approximatedate() might not be sufficient,
> since we need to establish which activity goes with which
> comment. (Note that I'm writing this off the top of my head and
> haven't looked at the approximateddate() code).

Good point. I was just thinking about seeing the activities between
the comments, as we're seeing more of now because of the AJAXification
of the bugs page, but lumped together, and de-duped.

Perhaps grouping with a related comment can be considered first, for
activity within a static ~5 minute window following the comment, then
the approximatedate() grouping could be applied.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r12131 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12131>.