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
It was not being copied which was causing that the allocation end date
was lost when an allocation is added for the first time. This caused
the resources per day to appear as less the next time the allocations
are shown.
FEA: ItEr62S05BugFixing
The taken effort must be added to the effort taken by the
day. Otherwise if the start date is in the middle of the day and the
allocation finishes the same day the calculated end is wrong.
FEA: ItEr62S05BugFixing
