Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0016371Openbravo ERPB. User interfacepublic2011-03-17 19:072011-03-19 00:00
Reporterplujan 
Assigned Tomarvintm 
PriorityurgentSeveritymajorReproducibilityrandom
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Versionpi 
Target Version3.0RC5Fixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0016371: You can randomly break the context making Purchase document types appearing in Sales Invoice
DescriptionIn a "broken" context, whenever you access Sales Invoice, the document type is displayed as AP Invoice (Purchase document type). This wrong behavior seems to be related with some wrong Session Variable.
The main problem is that the steps to reproduce it are unknown. Once broken, can be reproduced easly.
Steps To ReproduceRoughly, it might be related to messing with Purchase items and then moving to Sales.
I reproduced by running Procurement test cases of Smoke Test and then trying to create a Sales Invoice. However, I cannot be more precise on this.
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
Attached Filespng screenshot-29.png (30,609) 2011-03-17 19:07
https://issues.openbravo.com/file_download.php?file_id=3712&type=bug
png
Issue History
Date ModifiedUsernameFieldChange
2011-03-17 19:07plujanNew Issue
2011-03-17 19:07plujanAssigned To => marvintm
2011-03-17 19:07plujanFile Added: screenshot-29.png
2011-03-17 19:07plujanModules => Core
2011-03-17 19:57marvintmNote Added: 0035023
2011-03-17 20:17plujanTarget Version => 3.0RC5
2011-03-17 20:18plujanSummaryYou can randomly brake the context making Purchase document types appearing in Sales Invoice => You can randomly break the context making Purchase document types appearing in Sales Invoice
2011-03-17 20:19hgbotCheckin
2011-03-17 20:19hgbotNote Added: 0035024
2011-03-17 20:19hgbotStatusnew => resolved
2011-03-17 20:19hgbotResolutionopen => fixed
2011-03-17 20:19hgbotFixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/24a71cf73c5cfb4c8351ffcad7c392c2d73cb29a [^]
2011-03-18 12:57shuehnerNote Added: 0035040
2011-03-18 12:57shuehnerStatusresolved => closed
2011-03-19 00:00anonymoussf_bug_id0 => 3224010

Notes
(0035023)
marvintm   
2011-03-17 19:57   
This issue is very very hard to reproduce. The only way we've found to consistently reproduce it is:

- Make sure that in the Sales Invoice window, there is only one record.
- Logout, and login
- Go to the sales invoice window. A filter might prevent the only record from being viewed. Clear the filter.
- As there is only one record, it will automatically be selected. This causes the problem, as this is a FIC request in SETSESSION mode, without any content being sent. This causes the FIC to set the windowId|issotrx session variable incorrectly.
- From now on, when creating a new Sales Invoice, the problem will happen (wrong transaction documents will be shown, for instance).
(0035024)
hgbot   
2011-03-17 20:19   
Repository: erp/devel/pi
Changeset: 24a71cf73c5cfb4c8351ffcad7c392c2d73cb29a
Author: Antonio Moreno <antonio.moreno <at> openbravo.com>
Date: Thu Mar 17 20:18:01 2011 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/24a71cf73c5cfb4c8351ffcad7c392c2d73cb29a [^]

Fixed issue 16371. Send context info in all SETSESSION calls
Therefore, the FIC will set the correct value of the corresponding issotrx session attribute, and then the reported problem will not happen.

---
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/ob-toolbar.js
---
(0035040)
shuehner   
2011-03-18 12:57   
Reviewed & tested on pi/pgsql (rev: f416fdd08bf8). Patch adds missing parameter to SETSESSION call. With the changeset the specified failure can no longer be reproduced (now new action in sales invoice does list transaction document types for sales correctly when 1 record was present in the grid before the new action).