Tangentially related: we have some story aggregation code in the codebase which we used to use a long time ago. It aggregates notifications and feed stories (specifically: multiple updates to the same object by one or more editors in roughly the same period of time) into stories like this:

alincoln and htaft made multiple updates to T1234.

This code doesn't work right now since it predates ApplicationTransactions and hasn't been updated to support them, but wouldn't be too difficult to revive. Alternately, we could delete it. Does anyone have thoughts on what to do with it?

I think I favor deleting it, but I'm pretty open to going either way. I haven't experienced problems with notifications or feeds having too many stories about activity by multiple users on an object, and I think losing the information about what the update was is probably worse overall for me. However, this is also the only install I'm regularly exposed to now, and we're relatively low-volume.

Regardless of where we go with that, I'm going to move notifications to ApplicationSearch (this also will let you put them on a dashboard panel, which seems theoretically useful) and then probably implement a "group by object" mode to deal with this "catch up" use case, which I think is a pretty reasonable one and an easy display-time implementation. The existing aggregation doesn't aggregate stories more than 2 hours apart, so unless we both restore it and expand its role it wouldn't be a good fit for this use case.

(We could also restore aggregation but use it only in feed, or only in notifications. All of the options here feel about equal to me for how I use the product, at least.)

I fear this wouldn't make a busy install much less busy. I like the idea of more of a 'synopsis' type feed, as beyond just people on vacation, could be beneficial to people outside of engineering. Some sort of daily summary with links to queries (5 tasks opened today, 12 tasks closed, 5 diffs committed, yada yada yada).

I'm going to merge this into T12963, which isn't exactly the same but overlaps this substantially. It's possible we'll pursue a more narrow "vacation review" mode eventually, but we'd want to finish T12963 first and make sure it didn't adequately address this problem on its own.