Hi,

V3.1.4 fixes one bug in previous version : when not defining project for planning, all accessible projects are planned.
Before fixing, projects should be planned one by one only.
So tasks on some projets would not move, because availability would not be shared between projects..
This may explain why this tacks moved.

But could you give more information ?
Is the planned date correct depending on priorities, dependencies, availability of resources ... on all projects ?

To do this kind of analysis on all 67 projects will take a while...I believe that people involved in this project not involved into any other projects, so this should not affect this tasks. Moreover the previous group of tasks (Iteration1 ) which already started have not moved. And if the date in planned will be not 2014 but 2013 it all will be Ok

I have discovered some information - look at the enclosed screenshot for resource planning and you can see that for some reason some tasks are extremely long on this graph...

Hi,
Could you provide print for dates of the 3 "long" tasks.
The split of this tsks is strange.
For resource planning, you can have 2 parts in bars : grey part reflects the "real work" period. The green (or red if late) part reflect the "planed" period.
This split aims to point out tasks that are split, from real work already done to planned start.
What is stange for these tasks, is that real work bar ends must later than planned work...
It seems there is some real work in 2014...
Could you check this ?

Thank you very much - found task where real work been booked to 2014!!!
Now everything is OK!

May be we should have an option to set the limit how far in advance people can do real work allocation?

It is an interesting improvement.
Ticket #1001 registered.
One idea could be to forbid (or raise alert) when real work is entered after max(validated end date, planned end date) for a project.

Yes, very good idea.

Klaus