Page MenuHomePhabricator

Phabricator bots should not trigger notifications
Open, LowestPublic

Description

The revert job being done by @CommunityTechBot at T198552: Vandalism on Phabricator: Undo changes made (2018-07-01) is triggering notifications (the bell icon). While personally it doesn't bug me much, given that I don't have a lot of tasks watched, I feel Phabricator bots should be exempted from triggering notifications.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 1 2018, 8:48 PM
Restricted Application added a project: Upstream. · View Herald TranscriptJul 1 2018, 8:49 PM

Perhaps there should be a user preference implemented to turn off bot-generated notifications.

Or maybe have the bot suppress notifications when running a reversion job? Apparently you can make bulk edits "silent" (upstream T13042).

Aklapper triaged this task as Lowest priority.Jul 2 2018, 2:10 PM

Anyone can easily filter out mail notifications by filtering on the sender.

Anyone can easily filter out mail notifications by filtering on the sender.

Which works fine, until a new bot comes along. I guess that works, f we don't anticipate ever adding any more bots.

As far as I can see, you cannot filter web notifications by user (like I said above: the bell icon); only by actions taken on a task.

epriestley added a subscriber: epriestley.

It is intentional that bots trigger notifications and can not be silenced. This serves to prevent a rogue administrator from creating a bot, grabbing a bot API key, and then making a bunch of secret edits which don't notify anyone. Phabricator does not allow any user to act silently without CLI access.

In the future, we may provide a way to mark certain API keys as "silent" from the CLI, likely after refining the API key permissions model. You could then generate an API key with a subset of permissions (e.g., access to only specific API methods) and mark it as empowered to act silently from the CLI, which would also lock the permissions and prevent anyone from retrieving or regenerating the key from the web UI. However, this is probably some ways away since interest in a more granular API permissions model is currently fairly limited.