It worked!

Very happy to see that you guys are working on this, thank you. 👍

This is an unconstructive mess that I don't specifically plan to act on. T13069 and other work may eventually resolve this case indirectly.

report back on whether it mitigates

In T13265#245125, @brhodes wrote:

I merely wanted to have both possible resolutions on the table, one of which was to give the first message the ID later used In-Reply-To.

How old were things before the upgrade? (Roughly: less or more than about a year old?)

This previous behavior violated standards — the In-Reply-To identifier is supposed to be the Message-ID of a previously delivered email — but at least it wove a consistent fiction for mail clients.

Have you possibly changed mailers from "SES" to "SES via SMTP" or something like that? The logic here is basically:

See also https://phabricator.wikimedia.org/T113556 downstream.

See PHI1125. Recent versions of JIRA (JIRA 8?) still work with approximately the same instructions, but you have to fill out a modal dialog with about 7 required fields first, and none of the fields have real values. That is, the configuration instructions for recent JIRA are:

I'm going to consider this resolved at this point. The one thing I haven't built is the "task/point count" from the mocks (on the right-hand side of the header, counting points in each group), but I think this is probably only of much use under "Group by Owner", and maybe not even then. I'm open to building this in a future iteration and it's not likely to be very much work, I'd just like to see feedback that we're generally headed in the right direction first and that the element would have real-world use cases.

Currently, you can put a task in a column in these ways:

Currently, expected behavior.

More or less resolved previously in D14918.

D19549 added Spaces support to projects.

Mooted by D20263, which removes the rarely-used drag functionality from global lists.

We could lock this order into "drag to column" interactions only once those are built (i.e., not support "drag to position" -- basically, when you drop a card, we fling it into the correct position, even if that position is at the bottom of the column far off the screen). This will be somewhat confusing but maybe the least-bad of the options.

To summarize the state of the world here:

This now exists for priorities. I'd like to get at least one more grouping (likely: assignee) built before calling this resolved since "Priority" has some magic interaction with "subpriority". I'm moving toward getting rid of "subpriority" in D20263, but I'm not yet completely sure that it'll stick.

Drag-and-drop between columns on a priority-sorted board no longer changes priority. See T13074 for continuing adjacent work.

Some adjacent work in T13074 may build on this, and we might do "drag + shift" at some point, but this is substantially resolved.

I wholeheartedly agree that all that proxy field mess needs to go away. With that gone the only moderately confusing part remaining would be the way in which custom fields interact with herald, email and notifications.

An adjacent issue is that the current behavior of overheated queries is to return a partial result set and set a flag. The goal of this behavior is to let us show some results if we find some results, but it may be surprising if the caller doesn't handle overheated queries, since they may look like a queries which simply failed to match anything.

The hypothetical steps above do, in fact, reproduce this:

It seems that newer versions of git have become more aggressive at detecting binary changes as moves + renames, because my install is now hitting this on a very frequent basis

In the future, when a board can be ordered/grouped by author or assignee (or maybe custom fields), what should dragging a card within a column do?

Technical stuff:

Some old migrations call PhabricatorSearchWorker::queueDocumentForIndexing(). This no longer works after D20200 because the PHP implementation expects a dateCreated column to exist, but it won't exist until 20190220.daemon_worker.completed.02.sql runs.

Currently, if a card requires MFA to edit, we're unable to prompt the user. We likely should be able to do a prompt inline. This should also probably have a warning icon on the card itself.