T10334: On workboards, distinguish between "drag to column" and "drag to specific place in column"

I'm going to start here, and implement this proposed rule, which I think is the simpler and more intuitive of the proposals:

• When dragging cards between columns (source column is any column other than the destination column) on boards with sort orders other than "Natural", the action means "drag to column, without making other changes".
• Dragging a card within a column (source column and destination column are the same) will mean "make required changes".
• If we get feedback that people actually liked the old behavior (e.g., dragging to the top of a priority column raises priority), we can add a mode like "hold shift to drag the task exactly under your cursor".

This means that when you drag a card from column A to column B, the "ghost" of the card will sometimes jump away from your cursor, and may even jump off screen. For example, if you have a priority-ordered board and drag a "wishlist" card to a very tall column, the position of the card (now that we won't change the priority) may be near the bottom of the column, possibly below the field of view.

This isn't great, but I think there's not much we can do about it beyond providing visual feedback. When a drag operation targets a column, rather than a position, we can: highlight the column; show some "VVV" or "^^^" pointers up or down the column to wherever the card is; possibly show a "hit damage / quest objective" marker pointing at the card.

Since columns scroll independently, we could also: save the scroll position of the column, forcefully scroll it to the ghost, scroll it back once you drop or mouse out. I'm not sure if this will feel good or not, but we can give it a shot.

This will also resolve T8135: drag & drop on a workboard sorted by priority behavior is surprising.

T10335: When moving a card on a workboard will edit a task as a side effect, show an overlay hint

I'd like to add a tooltip hint card when dragging that shows what letting go of the mouse will do ("Move to column X; Change status to Closed"). Partly, this is a hint about drag-to-column vs drag-in-column (if we do adopt "shift", it could teach you how to use shift: "Hold shift to also: change priority to normal").

I'd originally imagined attaching this to the card itself, but if we're adding "move to column", that may not make as much sense (because the ghost of the card may not always be visible, and even if we scroll there will probably need to be some amount of animation on the scroll effect). The hints panel will also possibly become large later. Alternatively, we could statically position it (e.g., in the lower left), although the lower left interacts with notification bubbles; the lower right may obscure columns; and the upper corners are somewhat unusual. A lower-left placement with some interaction with the notification bubbles may make the most sense.

T10722: Communicate drag policies clearly in the workboard/list UIs

This is probably ripe before we move forward: when you can't drag a task because you don't have edit permission, we should visually indicate that it's locked and prevent you from picking it up with your cursor.

T10333: Add groups to workboard columns

This gets some discussion elsewhere too, but I think it's unambiguously a UI improvement once "move to column" vs "move to position" is sorted out.

T5474: Support workboard column triggers which activate when a task is dropped into a column

Once everything else is in place, I believe this is mostly about the trigger management UI (i.e., how does the UI work to let you manage complex groups of triggers that may affect multiple columns)?

I'm tentatively thinking we may try something like this:

• Quick access to selecting a single ad-hoc action, since I think most use will be "Close" with perhaps a handful of other things like "require assignment".
• Named groups of actions for more complex cases.
• "Copy-and-edit" for customizing one column without changing all the other columns using the same trigger rules.
• Rules are always referenced indirectly (not stored on the trigger) so copying a column just copies the pointer.

T11036: Put subproject columns on workboards

This is worth keeping in mind through the other changes, since it will add a new kind of situation where multiple copies of a card may be present on screen, and we need to keep track of where all the copies are and which copy you're dragging. In cases where we just hold cardUnderCursorPHID or similar, we won't be able to distinguish between different copies of the card, and will need to for "drag-between-columns" and "drag-within-column" to have different behavior.

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?

That is, if "Assigned To: epriestley" has three cards under it and I drag the bottom one to the top, what happens?

The expected behavior is pretty clearly "it moves to the top, with no other effects". This isn't currently possible to actually do since we don't have an ad-hoc way to store ordering within a given column under a given sort order, and we can't make any edit to a primary field to imply this ordering: one task can't be "more" assigned to epriestley than a different task.

Some other answers are more possible today, notably "you can't do that".

I'd like to try to make this do the intuitive/expected thing. I see two possible approaches:

1. Always order by "natural" at the end of everything.
2. Same as (1), but give each ordering its own "natural" positions.

The reason we might want (2) instead of (1) is that you may have tasks like this:

A (Low)
B (Low)
C (High)

You arrange them on the board in that "natural" order, then order/group by priority. This produces:

High
  C (High)
Low
  A (Low)
  B (Low)

Now, you drag "A" above "C". This updates its priority to "High" and its "natural" order to "above C". The view looks like this:

High
  A (High)
  C (High)
Low
  B (Low)

If you switch back to "natural" ordering, "A" has actually moved down the list even though you dragged it up. The new ordering is:

B (Low)
A (High)
C (High)

I suspect this is probably basically fine, but we could add an <..., order, ...> key to the column position table and store separate "natural" orderings for Unsorted, Priority, Assignee, etc., if it turns out to be confusing.

(In this particular case, we also don't actually need to update the ordering, but we would in some other cases where more cards are present.)

This implies:

• We remove drag-and-drop priority sorting from global list views. I think workboards pretty much mooted it anyway.
• We remove subpriorities and replace them with the fallback "natural" filter.

Overall, I think this likely simplifies a lot of code and gives us better behavior.

See PHI119. This may describe a race fixed by chaos reduction in T13054. PHI1128 is probably another copy of this, which suggests it's still a real bug.
See PHI208. This describes a performance issue on workboards with very large numbers of tasks.

These are closely related. The "chaos reduction" changes did not fix this.

PHI1128 describes a state where this occurs: in the database, a task was present in multiple columns in an illegal way. A single drag without any race fanciness was sufficient to trigger the issue, although the bad state may have required a race. The most immediate fix here is to recreate the bad state (put multiple column position rows in the database), perform the drag to reproduce the issue, then correct the code to recover from this case. This is probably straightforward.

Subproject columns (T11036) possibly have some adjacency here because they will allow this as a legal state (a card in different positions on multiple columns simultaneously). But I don't see any immediate/forced overlap -- we don't have a <boardPHID, objectPHID> unique key or anything which would make this state impossible to represent.

That leaves us with the question of how to get into this state in the first place, since it "should" be impossible. I suspect this is a race; I'll try to reproduce it.

PHI208 describes a vaguely adjacent issue where updates to the ColumnPosition table may take a long time if there are a large number of tasks (many thousands) in the column.

Currently, "column position" uses a relatively dumb algorithm where a large subset of the column must be updated when a card is moved. We previously had a fancier algorithm for "subpriority", although I removed it in moving away from "subpriority". It might be worthwhile to use this fancier algorithm for "column position". However, PHI208 also documents this kind of move as being generally more expensive than I'd expect and querying much more data than it should need to, so there may be simpler improvements available.

Upshot:

• Make drops when a column position already exists go through.
• Investigate execution of column position updates: why are so many projects being selected in PHI208?
• Investigate race conditions which could lead to multiple column position rows.

Make drops when a column position already exists go through.

I think the reproduction case in PHI1128 is actually more subtle.

Simply adding two position rows on the same board doesn't reproduce the exact same error, we get this instead:

This state is supposed to be "impossible" to arrive at in the application, but possible to represent in the database, and shouldn't fatal.

The PHI1128 case involved a milestone and is likely slightly more involved.

Simply adding two position rows on the same board doesn't reproduce the exact same error, we get this instead: [Unable to find...]

This is actually arising out of "dropping a task after a task which still exists on the client but no longer exists on the server causes a fatal because we can't figure out where to drop it", which is T12175. The best remedy is probably to send all cards above and below the card in the same group to the server, and let it fall back until it finds one that's still in the column or gives up. This might be a little slow in columns with thousands of tasks, but we could add an explicit cutoff.

See PHI119. PHI1128 is probably another copy of this, which suggests it's still a real bug.

I'm unable to figure out how to reproduce this. I'll consolidate it into a followup, although it's also possible that some other change here has fixed it.