Fix errant rules for associating projects when dragging tasks within a…


Fix errant rules for associating projects when dragging tasks within a milestone column

Fixes T10912. When you drag tasks within a milestone, we currently apply an overbroad, API-focused rule and add the parent board's project. This logic was added fairly recently, as part of T6027, to improve the behavior of API-originated moves.

Later on, this causes the task to toggle in and out of the parent project on every alternate drag.

This logic is also partially duplicated in the MoveController.

  • Add test coverage for this interaction.
  • Fix the logic so it accounts for subproject / milestone columns correctly.
  • Put all of the logic into the TransactionEditor, so the API gets the exact same rules.

Test Plan:

  • Added a failing test and made it pass.
  • Dragged tasks around within a milestone column:
    • Before patch: they got bogus project swaps on every other move.
    • After patch: projects didn't change (correct).
  • Dragged tasks around between normal and milestone columns.
    • Before patch: worked properly.
    • After patch: still works properly.

Here's what the bad changes look like, the task is swapping projects with every other move:

Screen Shot 2016-05-03 at 4.50.36 AM.png (166×698 px, 57 KB)

The "every other" is because the logic was trying to do this:

  • Add both the parent and milestone project.
  • Whichever one exists already gets dropped from the change list because it would have no effect.
  • The other one then applies.
  • In applying, it forces removal of the first one.
  • Then this process repeats in the other direction the next time through.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10912

Differential Revision: https://secure.phabricator.com/D15834