Page MenuHomePhabricator

Ability to exclude self ("Current Viewer") from Feed panels
Open, Needs TriagePublic

Description

I work at a relatively small company

I tend to batch my phabricator interactions.

Frequently I arrive passively attentive at my phabricator dashboard only after spending some amount of time attending to various tasks/diffs I'm assigned.

By the time I arrive there and see the (default) sidebar Recent Activity, all of the top stories are things I just did.

While I can scroll further down, I often lack the immediate inclination to do so, thus I miss an opportunity to gain passive information about what my coworkers are up to.

One can edit the query for the feed, but can only whitelist specific people.


This obviously is less relevant to companies with enough employees to have a high enough rate of change that things are frequently being done simultaneously to you

It seems like a logical analogue to the ability to disable self-action mail.

I searched to see if this had been asked before and didn't find anything; sorry if I missed it.

Event Timeline

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?

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