After doing an allocation if the task was moved to a place where it
cannot be satisfied the parameters specified by the user were
overriden with zero like values.
Now it keeps the fields originalTotalAssignment and resourcesPerDay so
if the allocation can be satisfied again it uses the original values.
FEA: ItEr66S04BugFixing
If doing an appropriative allocation it's necessary to unscheduled
element to make room enough for a gap, later those elements should be
schedule back again like it were unscheduled elements coming from the
list of unscheduled queue elements.
It's not possile to make any guess about in which queue it make fit,
as this may change depending on the new gaps created.
FEA: ItEr66OTS08CorreccionsRecursosLimitantesItEr65OTS04
Some dependency components were added more times than necessary. This
caused some troubles when a task was unscheduled or moved (some older
dependency components were removed but others didn't).
Refactor code, only add dependency component if they're going to be
shown in the planner.
FEA: ItEr66OTS08CorreccionsRecursosLimitantesItEr65OTS04
The scheduling window must do the scheduling according to the last
allocation direction. The start and end dates are updated depending on
the type of scheduling done.
FEA: ItEr66S04BugFixing
The order of the forces applied varies depending on the constraints
having priority or not. This works because the weak forces only use
the constraints of the task and if you have constraints for one point
you don't have them for the other.
FEA: ItEr66S04BugFixing
* Renamed war in order to use just navalplan instead of navalplanner-webapp.
* Renamed data source name for context.xml now using navalplan-ds.
FEA: ItEr66S03CommunityMaterialItEr65S04
* Modified debian/rules in order to a proper link to PostgreSQL Java library at /usr/share/tomcat6/lib.
* Also added lines to restart Tomcat in order to load this library.
FEA: ItEr66S03CommunityMaterialItEr65S04
In Tomcat 6 "/etc/tomcat6/context.xml" doesn't have a new line in the last one and this was causing troubles adding NavalPlan configuration.
FEA: ItEr66S03CommunityMaterialItEr65S04
When the calculated value was end date and the task was moved
backwards with a new end date that is before to the old start date and
the allocation cannot be satisfied, the start date picked would be
posterior to the new end. To avoid this, the dates must always be
recalculated taking into account the length.
FEA: ItEr66S04BugFixing
Ensuring that the variable with the resulting restrictions is not
null. When the task is fixed, this variable was not intialized.
FEA: ItEr66S04BugFixing
Sometimes in backward allocation after doing a resize the finish date
ends up being the same as before. In this case the TaskComponent is
not notified of the change. So now after resizing the properties of
the task are always updated.
FEA: ItEr66S04BugFixing
The problem lied in that the task's start date changed due to the task
being moved but the resource allocation keep on using its own date
instead of the new value. This leads to using a stale value for doing
the allocation. This can cause that the used start date was posterior
that the new end date as it happened in the exception.
FEA: ItEr66S04BugFixing
Manual allocation, either appropriative and non-appropriative, didn't
respect dependency constraints. Now manual allocation respects
dependencies in the same manner as automatic allocation
FEA: ItEr65OTS04CorreccionsRecursosLimitantes
