This was removed because of:
* It was not being used since June 2011 when we started to use "cutycapt"
command instead of "CutyCapt".
* "killall" command added a new dependency that was not marked in the Debian
packages. This causes some stacktrace in the logs of a fresh installation in a
Debian server.
FEA: ItEr76S04BugFixing
* BlockingQueue with size 1 could block some order saving till the queue was not
empty.
* Counter in order to check the maximum number of attempts was post-incremented,
so it was not working at all.
FEA: ItEr76S14ConcurrencyProblemWorkReports
Using the "dbms" attribute in "changeset" tag doesn't show any warning as if
database doesn't match the change is simply ignored.
FEA: ItEr76S14ConcurrencyProblemWorkReports
In order to do the recalculations is needed that the order is actually saved, so
it's better to call the DAO after doTheSaving method.
Moreover, now the DAO receive an id and look for the order in database.
FEA: ItEr76S14ConcurrencyProblemWorkReports
If an OrderElement is added or removed in the WBS and it is not a new object,
then the Order is marked to recalculate the SumChargedEfforts. During the Order
saving the SumChargedEfforts are recalculated.
FEA: ItEr76S14ConcurrencyProblemWorkReports
Now SumChargeEffort objects are not created till some hours are reported, so it
could be null in some cases.
FEA: ItEr76S14ConcurrencyProblemWorkReports
A database refactoring has been added to make this change keep working and avoid
lose any data.
It was needed to use specific procedures for PostgreSQL and MySQL.
FEA: ItEr76S14ConcurrencyProblemWorkReports
This fixes when you have a container task which is a scheduling point, and you
unschedule it to schedule its children. This is the opposite to the original
description of the bug, but the cause is the same.
FEA: ItEr76S04BugFixing
Possible fix of the first problem. It looks into the
SchedulingDataForVersion instead of the data to see the status in the
database instead of in memory so the synchronizations sent to the
database are ok.
This fixes when you have a container task which is a scheduling point, and you
unschedule it to schedule its children. This is the opposite to the original
description of the bug, but the cause is the same.
FEA: ItEr76S04BugFixing
Possible fix of the first problem. It looks into the
SchedulingDataForVersion instead of the data to see the status in the
database instead of in memory so the synchronizations sent to the
database are ok.
