Bugzilla – Bug 133976
TaskJuggler doesn't keep persistent allocations in projection mode
Last modified: 2005-11-18 11:10:06 UTC
1. Somwhere in a project define a task task broken "Will break allocations" { start 2005-01-01 effort 4d allocate tux { alternative tuxia persistent} } Let TaskJuggler pick a resource to do the job. 2. 2005-01-03 generate booking info for 2005-01-01 2005-01-03 period. You'll get something like this. supplement resource tux { plan:booking 2005-01-01-09:00:00-+0600 2005-01-02-17:00:00-+0600 broken } 3. Then add some tasks for tux/tuxia, and generate a scenario in a projection mode. Taskjuggler pick a resource for doing a rest of the "broken" task without taking tux booking into account. It could assign the rest of the task to tuxia if it likes to. This is because setLockedResource() is called only in Task.cpp on scheduling but not when reading supplemented bookings. And then Task::BookResources() is free to choose any resource it likes from the allocation list for rest of the job. As far as I see, there are two ways to fix a problem: 1. When reading bookings for resources not only add an allocation for a resource, but also call somehow Task::BookResources() to get things set right. This is not an easy way as Task::BookResources() logic deals with mandatory resources and this puts an _order_ of resource booking records in importantance. 2. When reading bookings for a task, iterate over all allocations where booked resource is mentioned _and_ allocation is mandatory. Then lock resource in those allocations.
Just spent a day trying to fix this bug. 1. I've coded a block to lock resources in readResourceScenarioAttribute() as following: if ((b = readBooking(sloppy)) == 0) return FALSE; + Task *bookedTask; + bookedTask = b->getTask(); + + if(bookedTask!=0) + { + for(QPtrListIterator<Allocation> t_a = +bookedTask->getAllocationIterator + (*t_a)!=0; + ++t_a) + { + if(!(*t_a)->isPersistent()) continue; + for(QPtrListIterator<Resource> +t_r((*t_a)->getCandidatesIterator()); + (*t_r)!=0; + ++t_r) + { + if(*t_r==resource) + { + (*t_a)->setLockedResource(*t_r); + } + } + } + } Unfortunately, this didn't work. At Task::BookResources() resource was somehow unlocked ! 2. After looking around, I've found that in Allocation::init() resource lock is reset in Allocation::init(). Allocation::init() is called from Task::prepareScenario(). Commenting out resource unlock in Allocation::init() did the job. Don't know if I break somethins else with this hack.
The reset in Allocation::init() is indeed important. But I was able to fix it in a slightly different way. The problem should be fixed in SVN now.