The manually introduced budget cell will be representing the total
amount for the budget on that item, and the expenses cell will
show the difference between that total and the resources costs
for the task hours and required criteria.
FEA: ItEr77S17AutomaticBudgeting
The budget cell will represent the total available budget, and the calculated
read-only total, will be the result of substracting the consumed budget due
to the hours and cost categories of the assinged task criteria.
FEA: ItEr77S17AutomaticBudgeting
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.
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)
There was some issue regarding connector_properties columns
names that was causing that the bootstraps launched an SQL
exception when deploying over MySQL.
FEA: ItEr77S04BugFixing
When the user had restricted access to the company view, and the list
of specific projects that he could read is empty, an HibernateQueryException
was being raised.
FEA: ItEr77S04BugFixing
When deploying again after having imported projects, the calendar bootstrap was wrongly trying to save
a repeated calendar exception day.
FEA: ItEr77S05BasicProjectImport
- In OrderSyncInfoDAO the method name findByKeyAndConnectorId is changed to findByKeyOrderAndConnectorId and
a parameter Order is added. The files that uses this method are modified accordingly
- In JiraSynchronizationController refresh added. If OrderSyncInfo is saved the jira sync info screen will be
updated to show the change
- OrderCRUDController refactored
- Save or update for OrderSyncInfo instead of creating new instance for each sync
- Name change for TimImpExpInfo to SynchronizationInfo
- JiraSyncInfo is removed instead SynchronizationInfo is used
- All files which are affected by name changes are modified
- Translations added where applicable
- clean up unused variables etc
- JIRA is moved to connectors and all files modified that has to do with this change.
- JiraConfiguration file is removed
- ImportedLabel attribute is deleted from Order and order.hbm.xml
- Imstead of importedLabel is now used the key from OrderSyncInfo
- and some more changes where applicable
Better error handling:
* check if connector connection values are valid
* New ConnectorException
* New .zul file to show import/export failed/success information
* All files modified affected by these changes
The component that shows the filtering results is adding the unscheduled projects when they
are not excluded by the dates range, but they were appearing also when they were not matching
the combobox conditions.
FEA: ItEr77S15FilteringEnhancements
* CRUD for scheduler
* The UI job_scheduling.zul for CRUD is splits to _editJobScheduling.zul and _listJobScheduling.zul
* Lots of changes in scheduler to make it generic
- jobs can be scheduled, rescheduled and deleted
- check if job has a connector and is enabled
- check if job is allowed to be scheduled
- do manual is moved to JobConfigurationController
* attributes connectorName and scheduled added to JobSchedulerConfiguration modified
* triggerGroup and triggerName deleted from JobScheduleerConfiguration
* In JobConfigurationDAO findByConnectorName added
* New JobClassNameEnum added to be used as data type for JobClassName in JobSchedulerConfiguration
* Import/Export Jobs read the beans that do the real work from ApplicationContext
* Some minor changes in ConfigurationController
AppProperties entity has been removed as it stores the same information
(majorId) repeated in each database record and it doesn't match with the real
model that we need.
A new entity Connector with a majorId identifier has been created, this entity
contains a list of properties (pairs key-value).
Moreover it has been created the predefined Tim connector with its own
properties (predefined too).
For new connectors, apart from the specific classes implementing them it would
be only needed to modify PredefinedConnectors and PredefinedConnectorProperties.
The database will be updated automatically on LibrePlan startup thanks to the
ConnectorBootstrap.
FEA: ItEr77S16JiraAndTimConnectorContributionIntegration
