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.

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:

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.

Another possible approach is to use -o LogLevel=ERROR. This gets us into trouble if there are useful INFO messages other than "permanently added X to list of known hosts", but presumably all the important stuff is rasied at ERROR or better.

For Drydock/Harbormaster, the only real way forward I see here is:

Currently, properties on upstream build steps are driven by CustomFields. T13248 briefly discusses a bit of context.

(This is likely to be very long, very rambling, and not particularly enlightening or useful.)

somewhat tricky to explain, and somewhat tricky to resolve

From onsite:

Thanks. That looks like a perfectly normal object to me so I'm not sure what could cause it to fail to load.

You will soon be able to give builds different "Hold Drafts" behaviors. See T13258.

After D20229, the rules are:

I'll call this out in the changelog, but behavior here is changing slightly (see T13258 and T11415):

I'll update the documentation/setup guidance in the upstream.

Great! Thanks for the report, and for your help tracking this down by going through the diagnostic steps.

Here's what's happening in general:

I can't immediately reproduce this: I can log into my local development install and into secure.phabricator.com using Google OAuth without any issues right now.