Avoid potential remote code execution through the `parameters`
parameter. They were concatenated to the capture command String
directly, which could lead to the injection of malicious code.
Currently the problem isn't exposed because the potential attacker
can't control the contents of the `parameters` map, since their
contents are chosen from a limited set of values.
FEA: ItEr77S17AutomaticBudgeting
As a method has been added to HourCostDAO to provide the PricePerHour associated
to a category, for an specific WorkHourType, the loading and attachment of
these objects is not longer needed here.
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)
