Page MenuHomePhabricator

Option to set/override email notification preferences on a self-hosted Phabricator instance
Closed, DuplicatePublic


Our problem:

Our company is transitioning to Phabricator in the last year but people have complained about the overwhelming amount on emails they receive once they register on the site. Even with the correct project/task/repo visibility settings it can be a little overwhelming. They often find themselves just ignoring all phabricator emails in gmail which is very bad.

I took the time to set the my notification settings in /settings/panel/emailpreferences/ but setting the same on every other account already registered into phabricator can take a lot of time and clicking. And especially hard when people don't really feel like doing it themselves.

Proposed solution:

  • Option to set instance specific default email preferences
  • CLI option to globally override notification preferences to the default


  • I tried searching to see if there is already a solution we could use (other than physically going around the company building and asking everyone to please sit down and set the notification options to something reasonable) but all I found is D5636 which was abandoned.
  • These are my current settings F709444 as you can see it's very different from the default "Everything is set to 'Email'"
    • This is basically what we would set as default because it fits our workflow

Event Timeline

gerx03 raised the priority of this task from to Normal.
gerx03 updated the task description. (Show Details)
gerx03 added a project: User Preferences.
gerx03 added a subscriber: gerx03.

T4103: Implement "Role Profiles" to provide search, homepage and application defaults is the way planned to handle the more general issue of "user preferences", and T5791: Write Herald rules for outbound mail will (I think?) address this issue specifically.

See also T8227: Why not just add an option/setting/preference?.

You could do a local hack (Like D5636) in your install, until your users are used handling things or until T5791 lands.

Yes, T4103 is the task for this. I'm going to merge this there.

T5791 offers a workaround and will be available soon, probably this week.

See also T7013 for some discussion. Particularly, I am interested in getting a better quantification of what "too much email" is and how it varies across users. Historically, when I actually looked at how much email the loudest "too much email" complainer was receiving, I was receiving 11x as much and handling it without any difficulty.

I'd eventually like to quantify:

  • How much email are users complaining about "too much email" actually receiving?
  • Are they receiving more mail than other users? That is, is how much mail you receive actually a predictor of how much mail you feel you receive, or is this partially or substantailly an issue of work habits / filters / time management?

The bin/mail volume command can start helping with that, but won't report complete numbers for about 30 days after the next upgrade.

T4103 and T5791 will provide technical means to reduce the amount of outbound email by default, but I worry that this is in large part ultimately a social/work habits problem with a bad incentive structure (users are incentivized to complain to admins because it's easier than changing habits; admins are incentivized to complain to us because it's easier than making users change habits). If this is true, those changes won't help very much.

In particular, reports in this vein are almost all "my users complain that they get too much email", not "my users complain that disabling unwanted email or writing filters is too hard / complex / time consuming / not possible" (there's some of that, but less of it than "too much email"). Even in this report, you show an example of a settings screen you'd like to use that probably took you less time to configure than it took your users to complain to you, and aren't asking for new or expanded filtering capabilities.

Generally, my guess is that:

  • We'll ship T4103 and T5791.
  • Many users will still complain about "too much email".
  • We'll better quantify this problem and discover that outbound mail volume is only weakly correlated to how much users complain about mail volume.

If this is the case, this problem is hard to make headway against:

  • We can possibly pursue some social fixes (e.g., show users how much mail they receive relative to others) but I worry they may not have much effect, and this starts to veer into policy-violating territory.
  • We can exercise the nuclear option (in T7013) and disable all mail by default. I think this is really bad, but it fixes the incentives from our point of view (administrators would need to explicitly turn on mail, so they'd have no reason to complain to us).