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

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0028242
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] A. Platformminoralways2014-11-20 19:142014-12-30 23:26
ReportercaristuView Statuspublic 
Assigned ToAugustoMauch 
PriorityurgentResolutionfixedFixed in Version3.0PR15Q1
StatusclosedFix in branchFixed in SCM revisiond945b70bfda4
ProjectionnoneETAnoneTarget Version3.0PR15Q1
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionpiSCM revision 
Review Assigned Toalostale
Web browser
ModulesCore
Regression levelProduction - Confirmed Stable
Regression date2013-11-07
Regression introduced in release3.0MP30
Regression introduced by commithttps://code.openbravo.com/erp/devel/pi/rev/cd5e1a38c069995d64d183c4e4e6d41259f5bed9 [^]
Triggers an Emergency PackNo
Summary

0028242: First request to load the window data is not done under some circumnstances

DescriptionFirst request to load the window data is not done under some circumnstances
Steps To Reproduce1) Go to the [Sales Order] window and create a new view personalization. Save it and set it as default
2) Go to the [Window Personalization] window and remove the record created for the personalization in step 1)
3) Log out and Log in
4) Open the [Sales Order] window again. Notice that the orders are not loaded unless you click on refresh window.
5) This behavior will continue until we remove the "Default View Setting" Preference created for this window

TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
caused by design defect 0024687 closeddbaz Double DataSource request when there using a saved view 
related to defect 0042270 closedcaristu Grid not properly initialized due to missing window personalization information 

-  Notes
(0071887)
AugustoMauch (administrator)
2014-11-21 13:51

The problem is the following:
- When a Saved View is created and set as default one entry is added to the Window Personalization table and another one to the Preferences window using the OBUIAPP_DefaultSavedView property.
- If the user deletes a record from the Window Personalization table the associated preference is not being automatically deleted.
- When the window that used to have a saved view is opened, the initial request is not done because it is detected that the view has a default saved view (by looking for the preference), and the second one is also not done because the window personalization action does not return any saved view (because the entry from the Window Personalization window was deleted)
(0071971)
hgbot (developer)
2014-11-25 12:10

Repository: erp/devel/pi
Changeset: f28687ecb081e26ffb596989b5c9b6c989b42b9e
Author: Augusto Mauch <augusto.mauch <at> openbravo.com>
Date: Tue Nov 25 11:51:55 2014 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/f28687ecb081e26ffb596989b5c9b6c989b42b9e [^]

Related with issue 28242: Delete preference along with window personalization

When a grid view is saved and set as default two records are added:
- One to the OBUIAPP_UIPersonalization with the description of the view
- One to the Preference table, using the OBUIAPP_DefaultSavedView property, whose value is the ID of the record added to the OBUIAPP_UIPersonalization table

The problem of this issue was that when the a default saved view was removed from the OBUIAPP_UIPersonalization table, its corresponding entry from the Preference table was not removed. This resulted in not making the initial request to load the grid because it was detected that the view had a default saved view (using the preference), and not doing it after loading the window personalization because the view description was removed from OBUIAPP_UIPersonalization.

The first step of the issue, included in this changeset, removes the Preference associated with a default saved view when it is deleted from OBUIAPP_UIPersonalization. This prevents the data from being inconsistent. The second and final step will consist in loading the grid even when the data is inconsistent, to fix the cases where the data is already inconsistent.

---
M modules/org.openbravo.client.application/src/org/openbravo/client/application/event/WindowPersonalizationEventHandler.java
---
(0071972)
hgbot (developer)
2014-11-25 12:10

Repository: erp/devel/pi
Changeset: d945b70bfda4976003686fb9ce6688495189521d
Author: Augusto Mauch <augusto.mauch <at> openbravo.com>
Date: Tue Nov 25 12:08:01 2014 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/d945b70bfda4976003686fb9ce6688495189521d [^]

Fixed issue 28242: Load grid even with inconsistent default view info

Before the previous changeset was applied, it was possible to have a preference that specified that a certain grid had a default saved view, but that the referenced default saved view did not actually exists. When this happened the grid was not loaded until the user pressed the Refresh button.

To fix this, now the inconsistent default view info is detected and the grid is loaded once it is detected that the default view does not actually exists.

---
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/main/ob-standard-view.js
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/main/ob-standard-window.js
---
(0072193)
alostale (manager)
2014-12-01 13:34

Tested, working fine in 2 cases:
1. When Window Personalization is deleted from UI, defaults pointing to that view are correctly removed
2. When Window Personalization is deleted from DB, default is kept but it work properly

Code review:
-Minor problem: this fix queries the list of preferences to delete, loads them in memory, iterates over this list to execute individual DB deletions on each of them. It would have been possible to directly remove from DB executing the "delete" statement for the required properties preventing in this way loading and iterating. Not reopening the issue because the expected amount of preferences to remove is small not being a big overhead in any case.
(0073135)
hudsonbot (developer)
2014-12-30 23:26

A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/6525fe229e06 [^]
Maturity status: Test
(0073136)
hudsonbot (developer)
2014-12-30 23:26

A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/6525fe229e06 [^]
Maturity status: Test

- Issue History
Date Modified Username Field Change
2014-11-20 19:14 caristu New Issue
2014-11-20 19:14 caristu Assigned To => AugustoMauch
2014-11-20 19:14 caristu Modules => Core
2014-11-20 19:14 caristu Resolution time => 1418857200
2014-11-20 19:14 caristu Triggers an Emergency Pack => No
2014-11-20 19:14 caristu Issue Monitored: networkb
2014-11-20 19:21 caristu Resolution time 1418857200 => 1418425200
2014-11-20 22:22 heccam Issue Monitored: heccam
2014-11-21 11:26 caristu Steps to Reproduce Updated View Revisions
2014-11-21 13:51 AugustoMauch Note Added: 0071887
2014-11-21 13:54 AugustoMauch Relationship added caused by 0024687
2014-11-21 13:55 AugustoMauch Regression level => Production - Confirmed Stable
2014-11-21 13:55 AugustoMauch Regression date => 2013-11-07
2014-11-21 13:55 AugustoMauch Regression introduced in release => 3.0MP30
2014-11-21 13:55 AugustoMauch Regression introduced by commit => https://code.openbravo.com/erp/devel/pi/rev/cd5e1a38c069995d64d183c4e4e6d41259f5bed9 [^]
2014-11-21 13:55 AugustoMauch Severity major => minor
2014-11-25 12:10 hgbot Checkin
2014-11-25 12:10 hgbot Note Added: 0071971
2014-11-25 12:10 hgbot Checkin
2014-11-25 12:10 hgbot Note Added: 0071972
2014-11-25 12:10 hgbot Status new => resolved
2014-11-25 12:10 hgbot Resolution open => fixed
2014-11-25 12:10 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/d945b70bfda4976003686fb9ce6688495189521d [^]
2014-12-01 13:34 alostale Review Assigned To => alostale
2014-12-01 13:34 alostale Note Added: 0072193
2014-12-01 13:34 alostale Status resolved => closed
2014-12-01 13:34 alostale Fixed in Version => 3.0PR15Q1
2014-12-30 23:26 hudsonbot Checkin
2014-12-30 23:26 hudsonbot Note Added: 0073135
2014-12-30 23:26 hudsonbot Checkin
2014-12-30 23:26 hudsonbot Note Added: 0073136
2019-11-13 18:28 caristu Relationship added related to 0042270


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker