This does not work as expected for tasks

[StingyJack]

I ran this on a bug that had a development task in the prior sprint, expecting that it would create a new task and transfer the remaining time and other details (but not completed time), assign that new task to the current sprint, and then close the prior task.

Instead it just set the current task to the base iteration. Why is it doing this, or how can I troubleshoot it?

[StingyJack]

OK, I see the bug on the first line of the performSplit function. Its using the parent workitem's iteration (Bug, US, PBI, etc) to look for the next iteration rather than looking at the task that is being split.

Since setting the iteration on a task is the only thing required to have the user story or bug show up in the sprint, and because user stories and bugs can sometimes span sprints, the iteration path is usually left blank (its extra unneeded effort, and setting it creates even more work when things slide over into the next sprint),

In my case it took a task for a prior iteration that had completed hours on it and set it to the next iteration for the bug, which is and will always be the base iteration. So there is another bug in this that it should not be moving anything that has completed hours on it into another sprint (or the base iteration)