Page MenuHomePhabricator

Maniphest email notification doesn't say why I'm receiving it
Closed, DuplicatePublic


As an email user, when I receive an email notification from phabricator I want to see at a glance what's my relation to the task and why I'm receiving the email, so that I can understand the message and what I am to do. To further help myself, I want to be able to set email filters to sort email in a fine-grained way.

Examples follow: from setting a herald notification on tasks created/assigned/cc'd to one user; and from a watched bugzilla user.

Example phabricator email

Thread-Topic: T6296: Offer "Do not notify me of changes when the task's subscribers change unless I am reporter of the task" setting
X-Herald-Rules: <79>, <80>, <85>, <90>
X-Phabricator-Projects: <#wikimedia>, <#maniphest>
X-Phabricator-To: <PHID-USER-vg42yoljioxdv5iac3py>
X-Phabricator-Cc: <PHID-USER-p2axfzcmoluit7llpzt2>
X-Phabricator-Cc: <PHID-USER-vg42yoljioxdv5iac3py>
X-Phabricator-Cc: <PHID-USER-7m5vr3h2wgau5fjkabs3>
X-Phabricator-Cc: <PHID-USER-wnf4fubsvi6l3gx4i7z6>
In-Reply-To: <>
References: <>
Thread-Index: NzdjMjQxMTIwYmEwOGRjZjgxYmUwMmY3NzA4IFQ700M=
X-Phabricator-Sent-This-Message: Yes
X-Mail-Transport-Agent: MetaMTA
X-Auto-Response-Suppress: All
X-Phabricator-Mail-Tags: <maniphest-column>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
X-SES-Outgoing: 2014.10.13-
Feedback-ID: us-east-1.ImFrbGFwcGVyIChBbmRyZSBLbGFwcGVyKSIgPG5vcmVwbHlAcGhhYnJpY2F0b3IuY29tPg==:AmazonSES

aklapper moved this task to Details on the Wikimedia workboard.


  Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>.

To: aklapper
Cc: qgil, aklapper, jeremyb, nemobis

Example bugzilla email

Subject: [Bug 64440] Language setting keeps resetting itself at kk:
Date: Tue, 16 Sep 2014 03:48:49 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: CC $person-email-redacted
X-Bugzilla-Product: MediaWiki
X-Bugzilla-Component: Language converter
X-Bugzilla-Version: unspecified
X-Bugzilla-Severity: normal
X-Bugzilla-Who: at.light@...
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: High
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: cc
Message-ID: <>
In-Reply-To: <>
References: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Auto-Submitted: auto-generated
MIME-Version: 1.0

This, that and the other (TTO) <at.light@...> changed:

           What    |Removed                     |Added
                 CC|                            |at.light@...

--- Comment #9 from This, that and the other (TTO) <at.light@...> ---
[1] looks suspicious. No other language converters set $wgLanguageCode...


You are receiving this mail because:
You are on the CC list for the bug.
You are watching someone on the CC list of the bug.

Example usage

a) I look up the notification footer most of the times: e.g. if a question is asked on a report I created I'm more likely to be expected to address it; if I voted the report this reminds me I care about it; if I'm just cc'd it might be anything.
b) I have email filter(s) depending on X-Bugzilla-Who, X-Bugzilla-Reason, X-Bugzilla-Watch-Reason.

Event Timeline

nemobis raised the priority of this task from to Needs Triage.
nemobis updated the task description. (Show Details)
nemobis added projects: Maniphest, Wikimedia.
nemobis added a subscriber: nemobis.

Can you break this task down into something more specifically actionable? What email did you receive from what, and what was not included in the footer that surprised you (sounds like Herald?)?

Well, why not implement all that bugzilla has? Is any of that especially difficult? I could break this down into headers and body footer, if that helps. Do you need a rationale for each header? (That was an email from herald, but those from "normal" relations to the tasks look the same. Unless no herald rule applies for the action, in which case maybe no X-Herald-Rules header will be added at all?)

T4778 goes a bit into detail about our team's size and ability to prioritize requests. This request certainly isn't unreasonable, I'd just like to see it more bite-sized and defined to improve it's chances. For example, adding Herald info in the footer would be useful for everyone I imagine.

Well, why not implement all that bugzilla has?

This is a slippery slope we generally don't prefer to travel. Phabricator covers a lot of ground with many different applications. Obviously some things make sense, so they do get added if we feel it's something that many installs will benefit from. In any 'feature request' situation we weigh the likely usefulness across all installs.

Is any of that especially difficult?

Any feature incurs both development time upfront and support/documentation/upkeep after. We are fairly picky about what hits the upstream because it's our time on the line. The number of one-off requests for features/options we get is fairly large.

I understand the constraints and that's the very reason I didn't (yet) split this up more: this is a feature request that can be satisfied on a "best effort" basis, doing what's easy and letting the rest be. I could make a rank of those 15 headers and 3*2 footers but the reality is that whatever portion of those gets fixed I'll be happier.

Maybe you have all that data at hand and are able to just cycle over it and dump it in email headers, or maybe it's extremely hard to gather and sanitise for that purpose. Maybe you prefer adding to the footer of the body, or maybe you think that's clutter. It's hard for me to tell what can help you prioritise or implement more easily...

PhoneixS triaged this task as Wishlist priority.Oct 16 2014, 8:12 AM
PhoneixS added a subscriber: PhoneixS.

Note overlap with T5791: Write Herald rules for outbound mail. (or possibly mergeable, with some details added?)

I know this is low on the food chain as far as requests but a thought...

I notice this in my headers:

X-Phabricator-Mail-Tags: <maniphest-cc>, <maniphest-comment>

Which for me does explain why I received an email from Maniphest.

It's possible that a more cross application header could be

X-Phabricator-Received-As: [Subscriber | Assignee | Author | Reviewer | etc ]

That way I could easily make a rule that says "short all mail received as a reviewer to here" and makes disambiguous the why of any email being sent.