When choosing a day it still doesn't show all the capacity information
correctly, but editing it works well.
FEA: ItEr68OTS05IntroducionLimiteSobreasignacionCalendarios
When an element is forced into a position (apropriative allocation) and
there's not room enough for allocating that element at that position,
it's necessary to unschedule elements in that queue until there's
room enough.
Before, all elements in a queue were unscheduled which guaranted the new
element would fit, but this caused that other elements could be rearranged
when it was not actually needed.
Now the algorithm only unschedules enough elements for fitting the
allocating element at the new position, instead of unscheduling the whole
queue since that position.
FEA: ItEr66OTS03AlgoritmosLimitantesItEr65OTS05
It's not necessary to call it as queues are refreshed later and its elements
are shown at their correct position. In addition, this method was
causing trouble as sometimes an element was successfully removed but not
sucessfully added to the same queue.
FEA: ItEr66OTS03AlgoritmosLimitantesItEr65OTS05
Once all new allocations are done, originally unschedule elements are
unschedule/schedule again, to force dependencies are satisfy
FEA: ItEr66OTS03AlgoritmosLimitantesItEr65OTS05
Now, when a queue element is allocated at a specific date:
* Unschedule all elements in target queue from that date on. If there's
already an element at that date, unschedule it too.
* Schedule those elements back in the queue in topological order. This
guarantees that dependencies are satisfied.
As a result, the new element is allocated at specified date and all the
elements after that day are shifted in the queue. If there were
dependencies between those shifted elements and other elements in the
queue, they will be shifted in their own queue too.
Take into account scheduling time when moving a task to a specific date.
Distinguish between how to generate day assigments between appropriate and
non-appropriative allocations.
FEA: ItEr66OTS03AlgoritmosLimitantesItEr65OTS05
The problem lied in that in advanced allocation perspective only the
task being modified was saved. Now the task's parents are updated and
saved too.
FEA: ItEr68S04BugFixing
Changes in resources load is filtered by criteria:
* second level tag: one row per generic resource allocation with the criteria names of the resource allocation.
* third level tag: one row per workers of the resource allocation with the name of the workers.
FEA : ItEr68S04BugFixing
Execute the next SQL sentences in your database if you want to keep working with
your current database:
UPDATE databasechangelog
SET md5sum='3:2e945615b34f87a232f914a37cbab56a'
WHERE id='add-new-column-enable_critical_chain_support' AND
author='jaragunde' AND
filename='src/main/resources/db.changelog-1.0.xml';
FEA: ItEr68S04BugFixing
Execute the next SQL sentences in your database if you want to keep working
with your current database:
UPDATE databasechangelog
SET md5sum='3:cb4aacdb6fe744a677baa0884ab4bc59'
WHERE id='add-new-column-enable_critical_chain_support' AND
author='jaragunde' AND
filename='src/main/resources/db.changelog-1.0.xml';
FEA: ItEr68S04BugFixing
Execute the next SQL sentences in your database if you want to keep working with
your current database:
UPDATE databasechangelog
SET md5sum='3:e32f913dd4429f4471ec850003dfc6d2'
WHERE id='add-new-column-enable_critical_chain_support' AND
author='jaragunde' AND
filename='src/main/resources/db.changelog-1.0.xml';
UPDATE databasechangelog
SET md5sum='3:71ae3b8d8998329d68e95d8ad2135745'
WHERE id='use-capacity-instead-of-effort_duration-and-not_over_assignable' AND
author='ogonzalez' AND
filename='src/main/resources/db.changelog-1.0.xml';
FEA: ItEr68S04BugFixing
