Page MenuHomePhabricator

Mail is still received after resigning from a revision
Closed, ResolvedPublic

Description

A user on our install reported this to me, but I'll try to provide as much detail as possible. Basically, we use project reviewers quite extensively. If we see a revision that we don't intend to review, the expectation is that we will resign from that revision. It seems, however, that we are still receiving emails from a revision even after resign from a revision. Here is a snippet from the /mail/ application.

See also PHI178.

Event Timeline

chad added a subscriber: chad.May 8 2017, 10:36 PM

Need version information, please.

  • There's probably one fairly narrow bug bug here: DifferentialTransactionEditor->getMailTo() likely includes resigned users but should not.
  • Beyond that, when you've resigned, we should probably exclude you from getting indirect mail via a project/package? Maybe? (But what if you meant "I'm not going to review this but still want to keep an eye on it" instead of "I'm not going to review this and don't care about it at all"?)

(But what if you meant "I'm not going to review this but still want to keep an eye on it" instead of "I'm not going to review this and don't care about it at all"?)

Isnt that what subscribers is for?

You can't explicitly subscribe to a revision you're a reviewer for because being a reviewer makes you an automatic subscriber (and, due to a similar bug to the one here, probably can't subscribe even if you've resigned, today), so you'd need to resign, then explicitly subscribe. Also, I'm not sure we handle the other way (explicitly unsubscribe, then later become a reviewer) correctly. These are tractable.

However, this stuff has been in HEAD for like 6 weeks or something and no one else has complained, so it's possible that almost everyone using "Resign" means "I still want email normally, just get it off my dashboard", and that jumping through all the hoops to implement this behavior in a more sophisticated way would actually make the product sort of worse in practice, even if it was more consistent/flexible.

I think we probably should still do it anyway, there's just some product subtlety here which wouldn't be present if the existing behavior was unambiguously undesirable (e.g., throws an exception and does not resign you).

epriestley updated the task description. (Show Details)Nov 1 2017, 6:10 PM