Page MenuHomePhabricator

Task creation no longer lists projects added (neither the UI nor mail notifications)
Closed, ResolvedPublic

Description

This seems to be a regression recently, as Wikimedia recently updated to stable version from 2016 Week 7. This may be fallout from D15065? I'm looking at the code to see if I can get to the bottom of it. I don't think it was an intentional change?

Example email:

Legoktm created this task.
Herald added subscribers: StudiesWorld, Aklapper.
TASK DESCRIPTION
I'm lazy, and it would be nice if the OOUI demos had a link to the jsduck docs somewhere.

Downstream bug reports:

From https://phabricator.wikimedia.org/T127282

In T127282#2071787, @mobrovac wrote:
In T127282#2042693, @legoktm wrote:

This is a huge functional regression for me. :(

+1 here too. When a new task is created, there's no mention of the associated projects in the e-mail body, which means I have to either (a) click on the link to see which projects the task is about; or (b) look at the source of the e-mail to see the headers. Both of those make my workflow less effective.

I can no longer easily identify new tasks that are in Security or a MW extension I watch or something I was explicitly cc'd on (usually higher priority).
X-Phabricator-Projects doesn't really work for me because tasks are often filed against multiple projects.

GMail doesn't allow automatic filtering based on arbitrary headers, so the header is more or less useless for me :/

Event Timeline

20after4 created this task.Mar 2 2016, 5:50 AM
chad added a subscriber: chad.Mar 2 2016, 5:59 AM

I have a vague feeling it's related to cleaning up the initial create transactions, that is, we used to show every field on the first transaction, which was silly since you could see what all the initial values are above.

Krenair added a subscriber: Krenair.

Yeah, this was mostly-intentional while resolving T9527 / T7661.

Previously, tasks often got 3-5 transactions on creation, some of which were just broken ("alincoln changed Security from None to None."), some of which were confusing or misleading ("alincoln shifted this task from space SX to SY."), and some of which were neither but not useful because the same information was reflected on the task itself ("alincoln added subscribers: alincoln").

Particularly after any field may have a default value with custom forms / ApplicationEditor, figuring out how to render these transactions in a way that isn't misleading is involved. The "alincoln shifted this task from space SX to SY" transaction meant, in some sense, "alincoln created this task, but changed the default form value from SX to SY while creating it", but that isn't obvious from the text. I don't immediately have a way to communicate this clearly for the projects/subscribers fields, either, which may be prefilled with some value and then partially changed to have different value. Stepping back, the total value any of these transactions ever provided seemed low, so I replaced them all with a single "created this <thing>" transaction.

Removing this information from email was a side effect that I didn't really consider explicitly, but I also haven't really missed it.

It looks like the root problem in all of the downstream reports is that projects, specifically, are no longer readily available (although they previously weren't on emails deeper in the thread, either).

(As noted downstream, they're present in the X-Phabricator-Projects header, but Gmail can't filter on headers. Per elsewhere, it would be nice if Gmail just supported this, but we understand that Google has very limited resources and that using Gmail as a mail client is galactic law.)

T5791 (roughly, "implement Gmail in Phabricator") is related; possibly we should also put human-readable projects in the human-readable mail body explicitly.

"implement Gmail in Phabricator"

Macro allthethings: IMPLEMENT ALL THE THINGS

It looks like the root problem in all of the downstream reports is that projects, specifically, are no longer readily available (although they previously weren't on emails deeper in the thread, either).

Yes, basically this. At least for my usecase, I mainly want to know the projects for my initial triage. For emails later in the thread, I already know what the ticket is about, so the specific projects are less important.

It's mainly the projects that I want to see as well. Although there has been talk of priorities etc. as well

This is particularly problematic in the UI when you need to revert the first change to a task since creation - there doesn't appear to be any way to find the initial assignee of https://phabricator.wikimedia.org/T129128#2105237 for example

We should probably change the text on "placed up for grabs" to "unassigned from X". I don't think we use that term anywhere else nowadays, either.

D15454 changes the wording to:

alice removed bob as the assignee of this task.

...which reads pretty clunky to me, but fixes the issue. If anyone can come up with better wording, I'm open to it.

qgil added a comment.May 18 2016, 1:18 PM

Is this task open to be Prioritized? Wikimedia is discussing the possibility to fund it at https://phabricator.wikimedia.org/T135327

I think we're mostly unsure what we want to do here.

@chad, do you have any HTML-ish mail ideas on, say, putting project tags in every mail? Even if we do find a nice way to present it, I'm not sure including project tags in every mail is actually desirable.

I don't particularly hate special casing this transaction ("X added projects: a, b." during creation) to appear in mail. I think the changes to create transactions in the web are generally good and like that it no longer appears on the web, but I can see the argument for retaining this transaction in mail where you can't see the tags in the curtain UI. I'm hesitant about adding weird special cases but I do think most of the special casing we've done so far is actually fairly good on the balance (but maybe because we generally do it as a last resort).

Let me see how involved the special case is.

chad added a comment.May 18 2016, 1:59 PM

Better to do the header tags in the body text thing?

I guess this originally had several different parts. My thinking on the parts are:

  • "X added projects: Y." transaction no longer renders in web UI when creating a task.
    • Intentional, happy with behavior (just look at the curtain), don't plan to change.
  • "X added projects: Y." transaction no longer renders in mail when creating a task.
    • Intentional, but this transaction providing some value makes sense to me (you can't just look elsewhere in the mail). It turns out it's easy to restore; D15942 restores it.
  • "X assigned this task to Y." transaction no longer renders in the web UI when creating a task, making it impossible to revert a later change if someone unassigns the task.
    • Intentional, but revert difficulty was not intentional. D15454 previously fixed this so transaction will say "X unassigned this task from Y" or whatever, instead of "X placed this task up for grabs", so you can revert the change by reading the transaction and then reassigning to Y.
  • X-Phabricator-Header isn't usable in Gmail.
    • Not new / not related to changes here, broader issue, probably resolve by embedding a bunch of invisible text in the mail footer, but maybe Gmail just implements this amazing feature from 1995 before we have to build anything. I think we'll address this elsewhere as part of broader "International galactic law mandates the use of Gmail at all times, but Gmail can't filter on headers" efforts.

I think D15942 is probably the best fix for the "this transaction is gone from mail".

An alternate fix would be putting tasks visible in the body/column/header/something. If you like this we can try that route, but I'm slightly-cooler-than-tepid on it and think D15942 is probably better. Partly I just can't imagine a good way to get all of an object's project tags into mail in a way that feels useful.

D15942 restores the project tag transaction to the first mail about an object:

alincoln added projects: Sculpting, Underwater.

So this isn't prioritizable because it's fixed in HEAD of master. (Let us know if anything got lost in translation, this task was a large ball of overlapping issues at one point and I might have focused on something other than what you intended.)