Page MenuHomePhabricator

Repositioning tasks within a Milestone column moves the task out of that milestone
Closed, ResolvedPublic

Description

If you can reproduce this bug, then I think it is a big one.

  1. Have a Project A with a Milestone 1 subproject.
  2. Get some tasks associated to Milestone 1.
  3. Go to Project A workboard in Natural view.
  4. Change the sorting of tasks in the Milestone 1 column (without moving the tasks out of that column).

EXPECTED

Nothing happens to the tasks themselves. They are still associated to Milestone 1.

ACTUALLY

Tasks moved within the Milestone 1 column are now associated with Project A, not anymore with Milestone 1. Even if in the Project 1 workboard they still appear in the Milestone 1 column. A little mess.

It happened in Wikimedia Phabricator:

I discovered this problem precisely the day that I repositioned dozens of tasks in two workboards... So much for tidy workboards. :) :/ :(

Event Timeline

epriestley triaged this task as Normal priority.

Thanks for the report! This is a definitely a bug, and should be fixed later today once D15834 is reviewed.


Unfortunately, I can't immediately come up with any completely easy/straightforward way to undo the negative effects of the bug. You can likely do this, but it's fairly technical:

  • Find the affected column PHIDs by querying the database (phabricator_project.project_column).
  • Find all tasks in those columns, also by querying the database (phabricator_project.project_columnposition).
  • Double check that your task PHIDs are for the tasks you expect (phabricator_maniphest.maniphest_task or task.search in the API).
  • Using the API, apply a projects.add transaction to each affected tasks, adding the milestone project PHID. (Do this on one task first to make sure it works, then the rest if that looks OK.)

This should be safe to do gradually and verify step-by-step, should have no effect on tasks were not moved improperly, and should fix tasks which were moved improperly. However, you have to fish around in the database/API to do it.


A simpler but slightly more manual approach is:

  • Look at one of the affected columns.
  • Copy all of the task IDs out of the UI.
  • Go to /maniphest/?ids=1,2,3,..., listing out all the task IDs.
  • Verify that the tasks found by the query are the ones you expect, and all of them belong to the same original column.
  • Use Select All and then Batch Edit Selected.
  • Add the appropriate milestone project to the tasks using the batch editor.

As above, this should fix the affected ones and have no effect on the good ones. You can try it with a single affected task first to make sure it works.

This is more cumbersome since you have to assemble the IDs manually and do one batch edit for each column, but doesn't require DB/API stuff.

It's also fine to not fix this, or just fix some of it -- the affected tasks shouldn't do anything bad or break anything, even though their state isn't totally consistent. They won't respond correctly to queries (e.g., querying for tasks in the milestone won't return affected tasks, since they aren't "really" part of the milestone anymore) but should behave normally other than that. So it's not critical to hunt down every single affected task.

Thank you for the quick fix! As for the fate of the misplaced tasks, don't worry, I'll deal with them.