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?
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.
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.
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.
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.
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.
I guess this originally had several different parts. My thinking on the parts are:
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.)