Page MenuHomePhabricator

Cannot disable email during batch operations
Closed, WontfixPublic


When you do a batch operation (eg remove a subscriber from many maniphest tasks), there is no way to disable email notifications caused by this action.

If we are trying to add/remove a list as a subscriber, then it will email firehose out.

Event Timeline

nipunn raised the priority of this task from to Needs Triage.
nipunn updated the task description. (Show Details)
nipunn added a project: Restricted Project.
nipunn added a subscriber: nipunn.

This is intentional: batch operations are just a more convenient way to apply normal operations to a large number of tasks. They respect policies, trigger Herald, create transactions, generate email and notifications, and cause other effects.

Can you describe the problem you're running into?

For example, do you routinely perform certain kinds of batch edits? If so, why?

Sure. I'll try to describe the problem we ran into.

We were trying to unsubscribe a mailing list from maniphest tasks. We originally had this mailing list automatically get added to all new maniphest tasks since when we had a smaller team, it made sense for everyone to watch everything by default. Now, as there were ~40 people on this list and ~3000 existing maniphest tasks in our backlog for this project, it didn't make sense, so we wanted to remove this mailing list from those 3000 tasks. However, we don't want to send 40 people 3000 emails each.

The best way to do this today is to pick an off-peak hour and completely disable phabricator emails for the whole company (~400 people affected) and do the bulk operation (~45 minutes). I was able to pull this off by emailing the whole company about the downtime, doing some bin/config mail adapter change, and running the bulk operations.

This felt suboptimal because I (with root access to our phabricator instance) had to babysit the operation, even though I wasn't directly working on the team it affected. It also affected many more people than it the minimal set. Bulk disabling emails is not something we will be able to do for much longer as a company.

epriestley claimed this task.

I think this isn't a very good use case for batch editing. This is an unusual administrative operation and probably best accomplished in other ways.

One approach would be to simply disable the mailing list user. They'd remain subscribed to the tasks and appear with a grey dot, but no longer receive mail. Another approach would be to have an administrator go into the user's settings and turn off email.

You can also do this in a few seconds by using a script something like this (untested):


require_once 'scripts/__init_script__.php';

// PHID of the user to unsubscribe from everything.
$user_phid = 'PHID-USER-...';

// Load all things they are subscribed to.
$subscribed = PhabricatorEdgeQuery::loadDestinationPHIDs(

$editor = new PhabricatorEdgeEditor();
foreach ($subscribed as $dst) {

I'd guess this script will take less than 10 seconds to run on 3K objects. It won't generate email, create transaction records, trigger Herald rules, etc.

This script took me about a minute write, so it would have cost you about $5 to just pay us to write the script for you. In exchange, you would have saved ~40 minutes of your time and not disrupted 400 other people.

angie moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jun 16 2015, 8:39 PM
angie moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jun 16 2015, 8:57 PM

Another option: after T5791 is closed, you could temporarily write a global Herald rule to disable emails for the actions you're about to take, then delete the rule when you're done.

Or asking Evan to write a script sounds reasonable.