Openbravo Issue Tracking System - Openbravo ERP |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0028242 | Openbravo ERP | A. Platform | public | 2014-11-20 19:14 | 2014-12-30 23:26 |
|
| Reporter | caristu | |
| Assigned To | AugustoMauch | |
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | |
| Platform | | OS | 5 | OS Version | |
| Product Version | pi | |
| Target Version | 3.0PR15Q1 | Fixed in Version | 3.0PR15Q1 | |
| Merge Request Status | |
| Review Assigned To | alostale |
| OBNetwork customer | |
| Web browser | |
| Modules | Core |
| Support ticket | |
| Regression level | Production - Confirmed Stable |
| Regression date | 2013-11-07 |
| Regression introduced in release | 3.0MP30 |
| Regression introduced by commit | https://code.openbravo.com/erp/devel/pi/rev/cd5e1a38c069995d64d183c4e4e6d41259f5bed9 [^] |
| Triggers an Emergency Pack | No |
|
| Summary | 0028242: First request to load the window data is not done under some circumnstances |
| Description | First request to load the window data is not done under some circumnstances |
| Steps To Reproduce | 1) 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
|
| Proposed Solution | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | | caused by | design defect | 0024687 | | closed | dbaz | Double DataSource request when there using a saved view | | related to | defect | 0042270 | | closed | caristu | Grid not properly initialized due to missing window personalization information |
|
| Attached Files | |
|
| 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 | bug_revision_view_page.php?rev_id=7121#r7121 |
| 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 |
|
Notes |
|
|
|
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
|
|
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
|
|
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
---
|
|
|
|
|
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. |
|
|
|
|
|
|
|
|
|