FEA: ItEr77S17AutomaticBudgeting
Several components were using Criteria collections not initialized on the
planning state, so when adding dinamically new CriterionRequirements
or HourGroups the group hours were not attached.
Since the scenario was created in the same transaction (due to using
@Before annotation) was not visible in givenOrderFromPrepareForCreate.
Now use a @BeforeTransaction instead so it's visible before.
Otherwise it creates a new Spring context instead of keeping using the
previous one.
This doesn't seem specially dangerous, but in some circumstances can
lead to idle transactions with associated locks that hang up the
execution of the tests. This happened with PostgreSQL version 9.1 in
WorkReportServiceTest.importValidDescriptionValuesToWorkReport().
Some test cases in DerivedAllocationGeneratorTest were failing during
a mvn install. It might not happen in all systems since it depends
on the order the tests are executed. It's also failing if run
individually.
The problem is that ScenarioBootstrap must be executed before
executing these tests. When distributing the resources, the
DayAssignments of the resource for the current scenario are queried.
An IScenarioManager must have been registered in Registry plus the
main scenario initialized.
The stack trace is:
java.lang.IllegalStateException: loadRequiredData should have been called on org.libreplan.business.scenar
ios.bootstrap.ScenariosBootstrap
at org.libreplan.business.scenarios.bootstrap.ScenariosBootstrap.getMain(ScenariosBootstrap.java:81)
...
at com.sun.proxy.$Proxy42.getMain(Unknown Source)
at org.libreplan.business.scenarios.OnlyMainScenarioAwareManager.getCurrent(OnlyMainScenarioAwareManager.java:38)
at org.libreplan.business.resources.entities.Resource$UsingScenarioManager.calculateAssignments(Resource.java:185)
at org.libreplan.business.resources.entities.Resource$DayAssignmentsState.getAssignments(Resource.java:172)
at org.libreplan.business.resources.entities.Resource.getAssignments(Resource.java:886)
at org.libreplan.business.resources.entities.Resource.getAssignmentsForDay(Resource.java:153)
at org.libreplan.business.resources.entities.Resource.getAssignedDurationDiscounting(Resource.java:861)
at org.libreplan.business.planner.entities.AssignedEffortForResource$AssignedEffortDiscounting.getAssignedDurationAt(AssignedEff
ortForResource.java:169)
at org.libreplan.business.planner.entities.EffortDistributor$ResourceWithDerivedData.withAvailableCapacityOn(EffortDistributor.j
ava:232)
at org.libreplan.business.planner.entities.EffortDistributor.resourcesFromMoreDesirableToLess(EffortDistributor.java:408)
at org.libreplan.business.planner.entities.EffortDistributor.assignAllPossibleWithoutOvertime(EffortDistributor.java:387)
at org.libreplan.business.planner.entities.EffortDistributor.distributeForDay_(EffortDistributor.java:356)
at org.libreplan.business.planner.entities.EffortDistributor.distributeForDay(EffortDistributor.java:341)
at org.libreplan.business.planner.entities.DerivedAllocationGenerator.createAssignments(DerivedAllocationGenerator.java:114)
at org.libreplan.business.planner.entities.DerivedAllocationGenerator.generate(DerivedAllocationGenerator.java:68)
at org.libreplan.business.test.planner.entities.DerivedAllocationGeneratorTest.forOneResourceTheHoursGeneratedAreGotFromAlpha(De
rivedAllocationGeneratorTest.java:205)
This reverts commit 9a8d7deffe7bb5034448f698ab3dff4014b1bdb1.
The original fix on the patch "Bug #1546: Force recalculation of critical path progresses on
saving project" is having a side-effect on the behaviour of the dependencies, that don't push
tasks and are show violated.
As the regression effect is more severe than the original bug, we revert the patch while finding
another solution for the original issue.
