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
if the window has already been initialized the tabpanels are reseted,
so that it is necessary to initialize the default controller,in this
case the OrderElementTreeController.
FEA : ItEr65S06BugFixing
Execute next sentence:
UPDATE databasechangelog SET md5sum='3:8a4ed0c0131906744a85a38278180e13' WHERE id='add scheduling mode' AND author='ogonzalez' AND filename='src/main/resources/db.changelog-initial.xml';
FEA: ItEr65S06BugFixing
Execute the next SQL sentence in your database if you want to keep working with your current database:
UPDATE databasechangelog SET md5sum='3:009cd5341d49b5415bf7ec539de24c79' WHERE id='add-company-logo-url-configuration-setting' AND author='ltilve' AND filename='src/main/resources/db.changelog-initial.xml';
UPDATE databasechangelog SET md5sum='3:2b767fd34386bfe53579516ddaccbdcc' WHERE id='add scheduling mode' AND author='ogonzalez' AND filename='src/main/resources/db.changelog-initial.xml';
UPDATE databasechangelog SET md5sum='3:53d99bb420a0c55c8eaa9389e3fc0ed5' WHERE id='add-scenarios-enabled-configuration-setting' AND author='ltilve' AND filename='src/main/resources/db.changelog-initial.xml';
FEA: ItEr65S06BugFixing
The method assignLimitingResourceQueueElement() allocates an limiting
resource queue element from the list of new queue elements to a queue.
Queue elements already in a queue might be affected by this allocation
(may change their position due to dependency constraints) and need to
redraw.
For redrawing each element, its queue is refreshing. Refreshing the
queueu causes to paint the elements in a new position an create new
dependency components, however the old dependecy components need to be
removed before.
FEA: ItEr65OTS04CorreccionsRecursosLimitantes
The parents recalculations were recalculating the secondary point,
this caused that a posterior recalculation for the secondary point of
the same task would say it has not modified the task. This caused the
depending recalculations to not be executed.
Now when doing the parent recalculation only the primary point is
modified.
FEA: ItEr65S06BugFixing
Execute the next SQL sentence in your database if you have already applied last changeset:
UPDATE databasechangelog SET md5sum='3:0ba5792ffc0bff2a1ce571047b008796' WHERE id='rename start_constraint_type in task and task milestone';
FEA: ItEr65S06BugFixing
