Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0016285
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] A. Platformminoralways2011-03-15 10:012011-04-07 00:00
ReporterrgorisView Statuspublic 
Assigned Tomtaal 
PriorityurgentResolutionfixedFixed in Versionpi
StatusclosedFix in branchpiFixed in SCM revision5f32bb22bf38
ProjectionnoneETAnoneTarget Version3.0RC6
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0016285: Opening form ("switching to form view") must have immediate response

DescriptionDouble clicking a row in the grid (or CTRL-F2 or ENTER or clicking form icon)opens the form view. Sometimes this can take up to 1 second, which is a bit too long without informing the user on the progress. Feedback must be provided.
Proposed SolutionSwitch to form view immediately and then start loading the fields and rendering them. Most important is that the action (button click, keyboard press or double click) immediately responds.
TagsNo tags attached.
Attached Filesdiff file icon 16285.diff [^] (1,319 bytes) 2011-03-24 12:12 [Show Content]

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
(0035290)
mtaal (manager)
2011-03-28 23:13

Rob,
The system first does a call to the server to get the default values of fields and then opens the form. This is by design and has replaced an earlier implementation which opened the form directly but first disabled the fields.

So what should it be, stay like it is or be changed back to the old behavior?

gr. Martin
(0035298)
rgoris (developer)
2011-03-29 10:14

Martin, definitely first open form instantly,then lo
ading
(0035348)
rgoris (developer)
2011-03-29 17:18

As a general rule, every click/doubleclick the user does, needs an immediate response. Then, if needed, a loading process indicator can be shown. In this case, disabling the fields for a short moment, is the best solution.
(0035413)
shuehner (administrator)
2011-03-31 12:29

Hmm i think that was just changed the opposite way. Some time ago the form did open and without values and the values where loaded and appeared after some delay.
Which several users complained about.
Now that behavior is different with all the form display being delayed and the form only painted in the final state always...

This bug now ask for changing this back again? reopening the old complains?
(0035416)
rgoris (developer)
2011-03-31 12:56

To my knowledge this change has not been discussed thoroughly, at least not with me. Either way, it is essential to have an immediate response. Since the delay is very short we can probably do without progress-feedback while the form is loading its values.

In case this causes a problem (perhaps the one you are referring to) we can then insert an interstitial progress/waiting indicator but this should be in-form then.

So steps to take:
1) Immediate action on doubleclick/formbutton/enter: form view opens instantly
2) Fields are disabled while loading
3) After trying (1) and (2) perhaps: add loading bar (candy bar) while loading fields.
(0035552)
hgbot (developer)
2011-04-04 14:19

Repository: erp/devel/pi
Changeset: 5f32bb22bf389c8ae88ae77de83c1b7152b73ca2
Author: Martin Taal <martin.taal <at> openbravo.com>
Date: Mon Apr 04 14:18:38 2011 +0200
URL: http://code.openbravo.com/erp/devel/pi/rev/5f32bb22bf389c8ae88ae77de83c1b7152b73ca2 [^]

Fixes issue 16285: Opening form (switching to form view) must have immediate response

---
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/ob-standard-view.js
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/ob-view-form.js
---
(0035635)
rgoris (developer)
2011-04-06 08:53

yay!

- Issue History
Date Modified Username Field Change
2011-03-15 10:01 rgoris New Issue
2011-03-15 10:01 rgoris Assigned To => alostale
2011-03-15 10:01 rgoris Modules => Core
2011-03-16 10:27 iperdomo Assigned To alostale => iperdomo
2011-03-16 10:27 iperdomo Priority high => urgent
2011-03-16 10:27 iperdomo Type feature request => defect
2011-03-16 10:27 iperdomo Target Version 3.0 => 3.0RC6
2011-03-16 10:27 iperdomo Status new => scheduled
2011-03-16 10:27 iperdomo fix_in_branch => pi
2011-03-24 12:12 iperdomo File Added: 16285.diff
2011-03-24 12:13 iperdomo Assigned To iperdomo => mtaal
2011-03-28 23:13 mtaal Note Added: 0035290
2011-03-28 23:13 mtaal Status scheduled => feedback
2011-03-29 10:14 rgoris Note Added: 0035298
2011-03-29 17:18 rgoris Note Added: 0035348
2011-03-31 12:29 shuehner Note Added: 0035413
2011-03-31 12:29 shuehner Issue Monitored: shuehner
2011-03-31 12:56 rgoris Note Added: 0035416
2011-04-01 13:37 rgoris Status feedback => scheduled
2011-04-04 14:19 hgbot Checkin
2011-04-04 14:19 hgbot Note Added: 0035552
2011-04-04 14:19 hgbot Status scheduled => resolved
2011-04-04 14:19 hgbot Resolution open => fixed
2011-04-04 14:19 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/5f32bb22bf389c8ae88ae77de83c1b7152b73ca2 [^]
2011-04-06 08:53 rgoris Note Added: 0035635
2011-04-06 08:53 rgoris Status resolved => closed
2011-04-06 08:53 rgoris Fixed in Version => pi
2011-04-07 00:00 anonymous sf_bug_id 0 => 3278045


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker