Otherwise in subsequent updates on a allocation with a consolidated
part the resources per day could be different than the specified in
the last modification.
FEA: ItEr62OTS04PlanificacionHaciaAtras
In the future the start will be defined by the aggregate of resource
allocations if the task is planned backwards.
FEA: ItEr62OTS04PlanificacionHaciaAtras
Now the superclass at ResourceAllocation can handle both cases. Some
new abstract methods at ResourceAllocation had to be added.
FEA: ItEr62OTS04PlanificacionHaciaAtras
It's unnecessary because it order is reloaded completely later from
OrderCRUDController.saveAndContinue(), in case of being a new object.
FEA: ItEr62S05BugFixing
The new end was not being calculated correctly. For durations lesser
than a day, getLengthMilliseconds returned zero. Now the parts that do
not reach a one day value are summed correctly.
FEA: ItEr62S05BugFixing
We do it to prevent deleted textboxes to be refreshed. Besides, the list has
been replaced with a map, for convenience.
FEA: ItEr62S08PerformanceOrderEdition
* The order code has been validated before the new code was generated.
* Commented out the lines doing the validation and marking as FIXME to review in the future.
FEA: ItEr62S05BugFixing
The application used to refresh the whole order elements tree to get the
updated values for the 'code' column. Now we only refresh that column.
FEA: ItEr62S08PerformanceOrderEdition
Instead of reloading all the object after saving, they are just marked as not
transient anymore. The performance of this operation is quite better.
FEA: ItEr62S08PerformanceOrderEdition
After saving the order in the order detail,
manageOrderElementAdvancesController is initialized and associated to
the order that is being saved. Then you go to the scheduling view
through a change of perspective and save. This causes the order to
increase its version number. If you return to the order detail view,
manageOrderElementAdvancesController keeps pointing to the former
Order. This is the reason that when executing its bussiness logic
fails with an org.hibernate.StaleObjectStateException.
Now when going back to the scheduling view the order is reloaded from
the DB and the controllers of each tab are set to null so they are
initialized on demand with the current Order instead of sticking to
the former one.
I think the problem was introduced at commit:
4bb7e1ffd4. The performance improvements
reported in that commit can be compromised by this.
FEA: ItEr62S05BugFixing
We prevent doing the calculation when the graph is shown. Now it's done when
the application starts, and updated when one of the involved entities changes.
FEA: ItEr62S03RFPerformanceCompanyView
We prevent doing the calculation when the graph is shown. Now it's done when
the application starts, and updated when one of the involved entities changes.
FEA: ItEr62S03RFPerformanceCompanyView
