Avoid uses of Mode#goToOrderMode that cause unnecessary repaintings
Now the mode is changed after hiding the previous tab, so the previous
tab is not repainted and the new tab is showed with the correct mode.
FEA: ItEr63S03BugFixing
* After creating a new dependency the server responded with a call to addAft for adding the dependecy. But as we were deleting all dependecy lines, addAft failed to find the hook point (where to add after)
* Now only the unlinked dependency (temporary) is deleted
FEA: ItEr02S03MigracionZK5
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
* When GanttPannel's zoomLevel is changed we have to update the timetracker and scroll the pannel, so
we need the timetracker's scrollLeft value. Instead of asking for it to the GanttPannel after the listener
is executed at Planner.java we will send both the selected zoomLevel and the scroll value. We replaced the
listener at the zul file and added a new listener at Planner's widget class. Currently we are only sending the
desired zoomLevel
FEA: ItEr02S03MigracionZK5
* 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
