Openbravo Issue Tracking System - Openbravo ERP |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0011844 | Openbravo ERP | B. User interface | public | 2009-12-22 13:47 | 2012-09-25 12:30 |
|
| Reporter | plujan | |
| Assigned To | marvintm | |
| Priority | low | Severity | major | Reproducibility | have not tried |
| Status | scheduled | Resolution | open | |
| Platform | | OS | 5 | OS Version | |
| Product Version | main | |
| Target Version | | Fixed in Version | | |
| Merge Request Status | |
| Review Assigned To | |
| OBNetwork customer | |
| Web browser | |
| Modules | Core |
| Support ticket | |
| Regression level | |
| Regression date | |
| Regression introduced in release | |
| Regression introduced by commit | |
| Triggers an Emergency Pack | No |
|
| Summary | 0011844: On new Rebuild window, "Elapsed time" is useless. It should be changed to "Remaining time" |
| Description | The new Rebuild window has a time meter to inform the user about the rebuild time. I see no use for such information, since the real time anyone is expecting is the remaining time.
It is also possible that if build do not finish in a proper way (not because an error in the build itself but some javascript related error) time elapsed continues running even if build has stopped running, resulting in misinformation. |
| Steps To Reproduce | |
| Proposed Solution | Show Remaining time instead of Elapsed time |
| Additional Information | |
| Tags | NewRebuildWindow-QA |
| Relationships | |
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2009-12-22 13:47 | plujan | New Issue | |
| 2009-12-22 13:47 | plujan | Assigned To | => marvintm |
| 2009-12-22 13:47 | plujan | Status | new => scheduled |
| 2009-12-22 13:47 | plujan | fix_in_branch | => pi |
| 2009-12-22 13:47 | plujan | Tag Attached: NewRebuildWindow-QA | |
| 2010-01-04 20:35 | shuehner | Note Added: 0023200 | |
| 2010-01-04 22:25 | plujan | Note Added: 0023206 | |
| 2010-01-05 10:38 | shuehner | Note Added: 0023216 | |
| 2012-01-30 11:06 | marvintm | Note Added: 0044684 | |
| 2012-01-30 11:06 | marvintm | Type | defect => design defect |
| 2012-01-30 11:06 | marvintm | fix_in_branch | pi => |
| 2012-01-30 12:04 | plujan | Note Added: 0044692 | |
| 2012-09-25 12:30 | AugustoMauch | Note Added: 0052551 | |
| 2012-09-25 12:30 | AugustoMauch | Priority | urgent => low |
|
Notes |
|
|
|
|
The remaining time is not known so probably the only viable solution is to remove the timer completely.. |
|
|
|
(0023206)
|
|
plujan
|
|
2010-01-04 22:25
|
|
|
I see not one but at least three ways to manage this issue. Estimate the remaining time is a good option (it can be done in several different ways). On the other hand, rejecting the issue is even simpler than your solution. |
|
|
|
|
Perhaps my comment was a bit short.., we could apply the usual way of measuring/saving old execution time and calculate an estimate for the time of a current rebuild run. But the very different execution times of the rebuild (depending on module and its size) make it very hard to get at least some accuracy in the estimate.
This is the reason why the 'remaining time' which was present in the initial UI design was removed in the first place. |
|
|
|
|
|
In order to fix this issue, a way to compute how much time it really takes to finish the build would need to be implemented. This would need extensive development of the build servlet. |
|
|
|
(0044692)
|
|
plujan
|
|
2012-01-30 12:04
|
|
|
That is not necessary true, marvintm. A mixed solution reducing change complexity and also giving useful and correct info to the user is possible. You should discuss the alternatives with the UX expert before analysing the impact of the change. |
|
|
|
|
|