Page MenuHomePhabricator

Email notification for "edited the task description" does not contain the actual content changes (diff) nor a link
Closed, ResolvedPublic

Assigned To
Authored By
Nov 25 2014, 8:42 AM
Referenced Files
F4171601: pasted_file
Jun 16 2016, 12:40 PM
Unknown Object (File)
Jun 16 2016, 12:36 PM
"Like" token, awarded by TerraCodes."Mountain of Wealth" token, awarded by Quiddity."Mountain of Wealth" token, awarded by Nemo_bis.


Glaisher edited the task description.
Glaisher set Security to none.


etc bla bla bla bla

Doesn't give me a diff, or a link to a diff.

Filed upstream as

Event Timeline

TTO raised the priority of this task from to Needs Triage.
TTO updated the task description. (Show Details)
TTO added a project: Phabricator.
TTO changed Security from none to None.
TTO added a subscriber: TTO.
Qgil triaged this task as Lowest priority.Nov 25 2014, 9:52 AM
Qgil edited projects, added Phabricator (Upstream); removed Phabricator.

For what is worth, this is what MediaWiki does as well.

Providing a diff in an email might sound like a good idea, until you get into details. No problem if it's just about adding a couple of lines, and you could even think of replicating the diff UI found on web using HTML. Now, let's look at more complex edits, and let's not forget that Phabricator defaults to plaintext emails. Do we really want to send emails with ++ -- lines to users that might or might not be used to this syntax?

To me this is a dubious case, and if our users can survive with it on MediaWiki, I don't see the need in upstreaming this request for Phabricator in the name of Wikimedia. Proposing to decline this task.

Aklapper renamed this task from Email notification for "edited the task description" is useless to Email notification for "edited the task description" does not contain the actual content changes (diff).Nov 29 2014, 10:23 PM

I don't see why it would be too difficult to provide a basic unified diff in the e-mail. From our perspective, most MediaWiki users are familiar with diffs (admittedly, side-by-side diffs, but it's not too hard for them to transfer that knowledge to unified diffs). And Phabricator's infamous "audience statement" does say that Phabricator is destined for technically-savvy users, so diffs ought not to be out of the question upstream.

I should also note that Bugzilla's e-mails provided a diff (in a table) of changes to the bug title, dependencies, etc. Here in Phabricator, the task description is now another one of those metadata fields (unlike in Bugzilla where it was an immutable comment), so I feel that we should get a diff of that as well.

The main reason I filed this task is that the current e-mail for this is rather sad. "Yeah, XYZ edited the task description; sorry, don't know any more." It could at least try a little bit harder and say "30 bytes added" or something like that, but providing a diff would be the most useful thing to do.

Qgil claimed this task.
In T75851#794683, @TTO wrote:

I don't see why it would be too difficult to provide a basic unified diff in the e-mail.

As said in my previous comment, MediaWiki doesn't do this either, and therefore Wikimedia users are used to it. Phabricator is not introducing any novelty by doing the same.

For these reasons, I don't feel this is a good request to be made upstream in the name of Wikimedia. You can report it at your own risk, if you want (see T1298 just in case it's useful).

Declining this task.

Is this "decline, closed" as in "you can have useful content in these e-mail messages over my dead body", or "declined, closed" as in "it's not enough of a problem for me to justify expending the resources necessary to fix this"? If the latter, then I suggest that "declined, closed" ought to be removed, and "needs a volunteer" left.

Right now, what I'm getting is an e-mail message that amounts to "Unknown changes were made to a task number you don't recognize with a task title that may be unintelligible to anyone except the original poster and/or have nothing to do with the new contents. Good luck figuring out whether you care about this." This isn't working for me.

I grant that MediaWiki doesn't send diffs in e-mail. However, MediaWiki's mail gives me a direct link to the relevant diffs, which Phabricator doesn't do. MediaWiki also gives me a watchlist with links to the diffs, which Phabricator also doesn't do. If "MediaWiki doesn't do that" is the justification, then let's talk about what MediaWiki DOES do, and how its multiple functionalities easily make up for not actually sending the text of the diff in e-mail. Sending me one-click access to the diff is a very big improvement over sending nothing at all.

Bugzilla gave me what I want for this, which was a simple HTML table that shows the old version and the new version. (It didn't do that for task descriptions, because they couldn't be changed.) If a MediaWiki-style diff is impossible, then how about we just send a copy of the entire task description along, with the first part labeled "NEW VERSION" and the second labeled "PREVIOUS VERSION"? It doesn't really sound that hard to me.

Qgil removed Qgil as the assignee of this task.

For what is worth, it is possible to configure the option for sending diffs of code patches via email: metamta.diffusion.inline-patches

This is for code in commits, not for text in comments, but at least it is a precedent that might be useful to sell the idea.

Quiddity renamed this task from Email notification for "edited the task description" does not contain the actual content changes (diff) to Email notification for "edited the task description" does not contain the actual content changes (diff) nor a link.Mar 22 2015, 5:17 PM
Quiddity updated the task description. (Show Details)

This is probably the maximum time-waster in Phabricator for me. I can ignore other bugs that mean that an action takes x + n seconds instead of x seconds because they affect me only when I want to do something and the extra n seconds are not that important, but this bug breaks my whole workflow where I (only) need to read my mails to see if I need to react to something. If someone would fix this, either upstream or locally, highly appreciated.

This is really, really, really annoying. I usually do my basic phabricator stuff in my mail program and only use the browser if I'm further interested or want to write something. The Edited-Mails are the only ones that break this workflow.

I agree that these task edit e-mails are aggravating. It's especially frustrating that, when discussing whether Phabricator should e-mail users by default about their own actions, the argument put forward was that the generated e-mail thread should be a full accounting of what happened to a task. And yet these incomplete task edit e-mails directly stand in the way of providing a complete record of actions to a task.

JIRA has this functionality. For HTML e-mails, JIRA does a visual diff, with red strikethrough for removed parts and green highlighted text showing what was added. For plaintext e-mails, JIRA simply includes the full text of the previous task description and the full text of the current task description. This is a bit ugly, particularly for tasks with long descriptions, but it's still better than Phabricator's current behavior.

@epriestley pointed out in that improving T75851 would be limited to HTML mail. As I use plain mail, I personally have no interest in funding that, but I'm not removing the candidate as others may use HTML mail.

@scfc, do any of these unicode-combining-character plain text diff variants render in a reasonable way in your plain text mail client? The intent is that the text "meow" is marked as removed, and the text "woof" is marked as added.

  • The dog said "m̶e̶o̶w̶ w̳o̳o̳f̳".
  • The dog said "m͓e͓o͓w͓ w̟o̟o̟f̟".
  • The dog said "m̌ěǒw̌ w̭o̭o̭f̭".

If not, can you suggest a way we could present diffs which would work well (e.g., be readable and relatively unambiguous) in plain text mail?

(They seem fairly bad to me on my system, but I'm having a hard time coming up with any better ideas.)

This looks resolved! Here's an email I've gotten today:

pasted_file (487×884 px, 54 KB)