Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0031901Openbravo ERPB. User interfacepublic2016-01-14 23:302016-03-17 10:55
Reporterrbianchini 
Assigned Tocaristu 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version3.0PR15Q3.3 
Target VersionFixed in Version3.0PR16Q2 
Merge Request Status
Review Assigned Toalostale
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0031901: decimal value can't be changed by trigger/observer after manual edition in form view
DescriptionIn form view when a trigger/observer tries to modify more than once a current value for a decimal field (implemented as BigDecimal in generated entity) that has been previously edited in UI, the value it receives as edited (current state in handler, new in trigger) is the one that was originally edited rather than current actual one.

The problem is caused by textualValue property which does not get updated after save if the actual value is modified, remaining unsynched with what is seen in UI. Value of this property is used to get the value on save only for BigDecimal instances, see [1].

[1] https://code.openbravo.com/erp/devel/pi/file/a4e7ab3c00b3/modules/org.openbravo.service.json/src/org/openbravo/service/json/JsonToDataConverter.java#l438 [^]

Steps To Reproduce1. Install attached module [1]
2. Open Platform Issues window
3. In form view create a new record and save (leave all fields as empty)
4. Edit description and save
   -> all 4 numeric fields are set to 0: OK (trigger and observer set 0)
5. Edit the 4 numeric fields setting 100 to all of them and save
   -> all 4 numeric fields are updated to 110: OK (trigger and observer add 10 to current value)
6. Edit description and save
   -> decimal fields (BD1 and BD2) remain as 110: ERROR they should have been updated to 120, note N1 and N2 value is now 120
7. Any subsequent description update remains these fields with 110 value
   -> ERROR: they should be updated on each description modification as N1 and N2 do


Observe that:
* Request for step 4 does not send textualValue for numeric fields as they have not been edited yet
* Request for step 5 sends 100 as textualValue
* Subsequent requests send 100 as textualValue


[1] Module description
Adds simple window (Platform issues) with 4 numeric fields
* N1 Integer: updated on each modification by an persistence event observer
* N2 Integer: updated on each modification by a trigger
* BD1 BigDecimal: updated on each modification by an persistence event observer
* BD2 BigDecimal: updated on each modification by a trigger
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
related to defect 00167893.0RC6 closed mtaal What you enter through the ERP it is different from what it is stored in the DB 
related to defect 00168183.0RC7 closed mtaal Save button in Product window doesn't work 
related to defect 00290923.0PR15Q2 closed AugustoMauch Data is not refreshed in form view after changing it with a trigger 
related to design defect 0031404 closed caristu setItemValue() function should be update "_textualValue" too 
related to defect 0031189 closed inigosanchez on change function is not working fine when the event is triggered by "TAB" key 
related to defect 00220253.0MP17 closed shankarb A line of an order cannot be saved in grid view when configuring the 2nd UOM 
related to defect 0023136 closed shankarb Quantity field behaves differently in Sales Order Line and Purchase Order Line 
related to defect 00230563.0MP21 closed shankarb Ordered Quantiy field of Sales Order is not properly auto filling the grouping separator 
related to defect 00284273.0PR15Q2 closed AugustoMauch Price is not rounded to calculate the line net amount in Create Lines process of Purchase Order 
related to defect 0020474 closed mtaal When you save a register in grid view, amounts fields change to the previous value 
related to defect 00255173.0PR14Q3 closed shankarb Wrong calculations on numeric field depending on the formula 
related to defect 0032051 acknowledged Triage Platform Base review and remove occurrences of new BigDecimal(double) 
related to defect 0032668 closed alostale Wrong Total Gross Amount, Total Net Amount and Tax information is obtained in order and invoices 
causes defect 00322023.0PR16Q2 closed caristu Error in add payment when editing the amount of a record in order/invoice grid 
Attached Filesgz evenhandler.tar.gz (1,489) 2016-01-14 23:30
https://issues.openbravo.com/file_download.php?file_id=8924&type=bug
? org.openbravo.platform.issues-0.0.0.obx (17,011) 2016-01-19 11:07
https://issues.openbravo.com/file_download.php?file_id=8941&type=bug
Issue History
Date ModifiedUsernameFieldChange
2016-01-14 23:30rbianchiniNew Issue
2016-01-14 23:30rbianchiniAssigned To => platform
2016-01-14 23:30rbianchiniFile Added: evenhandler.tar.gz
2016-01-14 23:30rbianchiniModules => Core
2016-01-14 23:30rbianchiniResolution time => 1453431600
2016-01-14 23:30rbianchiniTriggers an Emergency Pack => No
2016-01-15 13:27alostaleNote Added: 0083351
2016-01-15 13:27alostaleAssigned Toplatform => rbianchini
2016-01-15 13:27alostaleStatusnew => feedback
2016-01-18 21:28rbianchiniAssigned Torbianchini => alostale
2016-01-18 21:28rbianchiniStatusfeedback => new
2016-01-18 21:29rbianchiniSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=10669#r10669
2016-01-19 11:07alostaleResolution time1453431600 => 1453417200
2016-01-19 11:07alostaleSummaryError in Event Handler's event.currentState => can't change by trigger/observer manually edited decimal value in form
2016-01-19 11:07alostaleDescription Updatedbug_revision_view_page.php?rev_id=10686#r10686
2016-01-19 11:07alostaleSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=10687#r10687
2016-01-19 11:07alostaleFile Added: org.openbravo.platform.issues-0.0.0.obx
2016-01-19 11:09alostaleRelationship addedrelated to 0016789
2016-01-19 11:09alostaleRelationship addedrelated to 0016818
2016-01-19 11:10alostaleRelationship addedrelated to 0029092
2016-01-19 11:10alostaleRelationship addedrelated to 0031404
2016-01-19 11:10alostaleRelationship addedrelated to 0031189
2016-01-19 11:12alostaleRelationship addedrelated to 0022025
2016-01-19 11:14alostaleSummarycan't change by trigger/observer manually edited decimal value in form => decimal value can't be changed by trigger/observer after manual edition in form view
2016-01-19 12:20alostaleStatusnew => scheduled
2016-01-19 12:20alostaleAssigned Toalostale => caristu
2016-01-25 12:49caristuRelationship addedrelated to 0023136
2016-01-25 12:50caristuRelationship addedrelated to 0023056
2016-01-25 12:51caristuRelationship addedrelated to 0028427
2016-01-25 12:52caristuRelationship addedrelated to 0020474
2016-01-25 17:09caristuRelationship addedrelated to 0025517
2016-01-25 17:41caristuNote Added: 0083593
2016-01-25 17:48caristuNote Edited: 0083593bug_revision_view_page.php?bugnote_id=0083593#r10760
2016-01-25 18:50caristuReview Assigned To => alostale
2016-01-25 18:50caristuAssigned Tocaristu => alostale
2016-01-25 18:50hgbotCheckin
2016-01-25 18:50hgbotNote Added: 0083595
2016-01-25 18:50hgbotStatusscheduled => resolved
2016-01-25 18:50hgbotResolutionopen => fixed
2016-01-25 18:50hgbotFixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/69d968879453d377cda8501a1cf0a6c9772d3693 [^]
2016-01-25 19:05caristuIssue Monitored: alostale
2016-01-26 10:59caristuAssigned Toalostale => caristu
2016-01-29 08:57alostaleNote Added: 0083707
2016-01-29 08:57alostaleStatusresolved => closed
2016-01-29 08:57alostaleFixed in Version => 3.0PR16Q2
2016-01-29 09:04alostaleRelationship addedrelated to 0032051
2016-02-11 15:45caristuRelationship addedcauses 0032202
2016-03-17 10:55hudsonbotCheckin
2016-03-17 10:55hudsonbotNote Added: 0085080
2016-04-26 08:42alostaleRelationship addedrelated to 0032668

Notes
(0083351)
alostale   
2016-01-15 13:27   
I'm not able to understand current steps to reproduce. Please make them simpler.

Description is not clear enough: current state gives me correct values in all handler's execution. Please update it also to better reflect the actual issue.
(0083593)
caristu   
2016-01-25 17:41   
(edited on: 2016-01-25 17:48)
The textual representation of number items (textualValue) was introduced to prevent rounding errors (0016789). On the server that value is translated back to a number using BigDecimal. Using a double value to instantiate a BigDecimal could cause rounding issues.

This problem was not completely solved with textualValue, because it is possible to reproduce that rounding issue in those cases where the value is not edited from the UI.

For example, following the steps to reproduce, if we increment a decimal value (11.2) instead of 10 in the event handler, the following value is stored in the database for the field BD1: 22.399999999999999289457264239899814128875732421875 while in the UI we see: 22.4
(0083595)
hgbot   
2016-01-25 18:50   
Repository: erp/devel/pi
Changeset: 69d968879453d377cda8501a1cf0a6c9772d3693
Author: Carlos Aristu <carlos.aristu <at> openbravo.com>
Date: Mon Jan 25 18:46:51 2016 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/69d968879453d377cda8501a1cf0a6c9772d3693 [^]

fixes issue 31901: can't edit decimal value with observer after manual edition

The decimal fields were using a property called textualValue to prevent rounding errors. This is because when instantiating a BigDecimal using a double value, it converts the entire precision of the double. Then, on the server, the textual value was translated back to a number using BigDecimal avoiding the rounding problem.

In this case the problem was caused because the textualValue was not being synchronized properly with the current value. To solve the problem, the textualValue property is not longer used and the textual conversion is done in the server: using the BigDecimal.valueOf method the double value is converted to a string internally, and finally that value is converted into a BigDecimal.

Thus, we do not need to worry about keeping textualValue synchronized and the double value is rounded properly using BigDecimal.valueOf()

---
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/form/formitem/ob-formitem-number.js
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/form/ob-view-form.js
M modules/org.openbravo.service.json/src/org/openbravo/service/json/JsonToDataConverter.java
---
(0083707)
alostale   
2016-01-29 08:57   
code reviewed

tested related issues
(0085080)
hudsonbot   
2016-03-17 10:55   
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/b22fb0500156 [^]
Maturity status: Test