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
it sorts the list by company name.
it changes a label by other one to facilitate the understanding.
it adds the delete operation of a company with some constraints.
FEA : ItEr67S04BugFixing
The error was happening due to using Dates instead of LocalDates. The
start of the satisfaction was in the middle of a day and the received
Date was at the start, so the first day was considered outside of the
criterion satisfaction's interval. Criterion satisfactions now use
LocalDates instead of Dates and this problem is fixed.
FEA: ItEr67S04BugFixing
The named parameter must be provided always otherwise this can happen:
Caused by: org.hibernate.QueryException: Not all named parameters have been set: [name] [Select t from OrderElementTemplate t where t.parent = NULL and LOWER(t.infoComponent.name) like LOWER(:name)]
at org.hibernate.impl.AbstractQueryImpl.verifyParameters(AbstractQueryImpl.java:291)
FEA: ItEr67S04BugFixing
This exception was happening:
java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.
at java.math.BigDecimal.divide(BigDecimal.java:1616)
at org.navalplanner.business.orders.daos.OrderElementDAO.average(OrderElementDAO.java:345)
at org.navalplanner.business.orders.daos.OrderElementDAO.calculateAverageEstimatedHours(OrderElementDAO.java:334)
FEA: ItEr67S04BugFixing
Initializing the hours group with the introduced hours parameter. It's
also needed to assign it a code, otherwise it would fail when saving.
FEA: ItEr67S04BugFixing
The minusDuration contained an error that caused to reach the end of
the loop before it should.
When calculating the current duration, the workable days given were
the rounded up version which caused the problem in the third snapshot.
FEA: ItEr67S04BugFixing
It avoids exception when doing a reassignation and there is an
unsatisfied generic allocation. Now in that case new resources mathing
the criterions are queried.
FEA: ItEr66S04BugFixing
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
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
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
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
