In general some kind of batching (e.g. "Donald commented on T### , approved D###, did it N other actions, click to expand") would also address this, but a view level filter seemed like an easier ask

I think this is reasonable to pursue, but I'd like to put the capability at the ApplicationSearch level rather than making it specific to one field in Feed -- basically, provide not(user) and not-viewer() or typeahead functions (or similar functions with better names).

We don't currently have a generic way to pass relational logic like this from the UI to the query layer for simple PHID fields like "Author". We do for Edges (which powers the not(project), or(project), etc., functions) and this case is simpler than edges are, so this is likely not especially difficult to build. However, it's not trivial either and I'm not sure how much code can or should be shared between Edges and normal fields. The most reasonable answer may be "some", which might motivate at least partially restructuring some of the existing Edge relationship stuff (the query-level parts of it feel good to me today, but the intermediate handoff part where logic is passed from the UI to the query level feels a little bit shaky).

At the same time, I think merging feed stories is also reasonable. We actually used to do this, but it was a little janky and not hugely useful. The old feed code was generalized around the time of ApplicationTransactions and this was removed as part of simplifying that generalization, I think.

However, in the old code (and any future code) I'm inclined only to group stories which we can reasonably and completely represent as a single story. Basically, in the form of:

• alincoln made several different changes to the same object.
• alincoln made the same change to several different objects.
• Several different people made the same change to the same object. (I think this only really happens with comments, which I'd want to keep separate?)
• As a special case, two-part actions like merges and mentions where we currently publish both "X merged into Y" and "Y was merged into X".

...but probably not:

• alincoln made several different changes to several different objects.
• Several different people made several different changes to several different objects.

Stories of the first type don't need to "click to expand", since we can write a reasonable story title like:

alincoln added the project "Example" to: X, Y, Z.

...but stories of the second type would since we can't really write a story title other than "a bunch of stuff happened".

I expect we'll build this again eventually, but it probably won't address this particular use case of folding up all of some user's different actions on different objects (however, it might fold up enough of those actions that there's less need for this).

This would also be useful for the Audit dashboard, e.g. to build the query "what audits am I responsible for that I didn't author?" (given that the viewer belongs to a project which is responsible for auditing the commit).

Is that feedback based on the Audit dashboard at HEAD of master?

Particularly, see T9430.

Yep, this is no longer a problem with the new audit bucketing. 🏅