Page MenuHomePhabricator

Hide revision dependency stories from feed/notifications
ClosedPublic

Authored by epriestley on Apr 16 2019, 7:56 PM.
Tags
None
Referenced Files
F13050719: D20437.id48766.diff
Fri, Apr 19, 3:09 AM
F13050717: D20437.id48765.diff
Fri, Apr 19, 3:09 AM
F13050716: D20437.id48742.diff
Fri, Apr 19, 3:09 AM
F13050714: D20437.id.diff
Fri, Apr 19, 3:09 AM
Unknown Object (File)
Thu, Apr 11, 9:25 AM
Unknown Object (File)
Thu, Apr 11, 4:16 AM
Unknown Object (File)
Sun, Mar 24, 7:44 AM
Unknown Object (File)
Mar 10 2024, 3:39 AM
Subscribers
None
Tokens
"Baby Tequila" token, awarded by amckinley.

Details

Summary

See PHI1134. Generally, "alice added a dependent revision: ..." isn't a very interesting story. This relationship itself is valuable, but the creation of the relationship is usually pretty obvious from context.

In the specific case of PHI1134, various scripts are racing one another, but I don't think this story is of much value in the general case anyway.

Test Plan

Edited parent/child revisions, no more feed stories.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

I feel kinda similarly about getting a flurry of "added commit to TXXX" notifications that fire in addition to the "bob closed DXXX" notifications. We don't have the infrastructure to say stuff like "only hide this notification if the same action already generated a separate notification of type foo, do we?

This revision is now accepted and ready to land.Apr 17 2019, 9:30 PM

All the same underlying action:

Screen Shot 2019-04-17 at 2.30.42 PM.png (465×406 px, 76 KB)

only hide this notification if the same action already generated a separate notification of type foo, do we?

In the absolutely most general case, we can't do this because metamta.one-mail-per-recipient may be off, and alice may only be on the task, while bailey is only on the revision, so we have to send both so that each of alice and bailey get at least one email.

At the moment, both of these emails come from the same task so they could interact, but this may not be true for long.

A half-step might be to just silence "added a commit to" in all cases? I'm not sure that's ever really interesting. That wouldn't silence "closed task X by committing Y", just the cases where a commit gets attached without affecting the task status.

At the moment, both of these emails come from the same task

That is, from the same GitMessageParserWorker task in the task queue, not "from the same Maniphest task" in some sort of virtual sense.

A half-step might be to just silence "added a commit to" in all cases?

Yeah that's fine with me; I was just thinking that users with flows that don't involve Differential revisions might still want to be notified about the attached commit. But that^^ would improve my life, so I'm in favor of it.

  • At least for the moment, fully silence the "commit/task" edges, too.
This revision was automatically updated to reflect the committed changes.