Anonymous | Login
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] B. User interfacemajoralways2016-01-14 23:302016-03-17 10:55
ReporterrbianchiniView Statuspublic 
Assigned Tocaristu 
PrioritynormalResolutionfixedFixed in Version3.0PR16Q2
StatusclosedFix in branchFixed in SCM revision69d968879453
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product Version3.0PR15Q3.3SCM revision 
Review Assigned Toalostale
Web browser
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo

0031901: 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] [^]

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
TagsNo tags attached.
Attached Filesgz file icon evenhandler.tar.gz [^] (1,489 bytes) 2016-01-14 23:30
? file icon org.openbravo.platform.issues-0.0.0.obx [^] (17,011 bytes) 2016-01-19 11:07

- Relationships Relation Graph ] Dependency Graph ]
related to defect 00167893.0RC6 closedmtaal What you enter through the ERP it is different from what it is stored in the DB 
related to defect 00168183.0RC7 closedmtaal Save button in Product window doesn't work 
related to defect 00290923.0PR15Q2 closedAugustoMauch Data is not refreshed in form view after changing it with a trigger 
related to design defect 0031404 closedcaristu setItemValue() function should be update "_textualValue" too 
related to defect 0031189 closedinigosanchez on change function is not working fine when the event is triggered by "TAB" key 
related to defect 00220253.0MP17 closedshankarb A line of an order cannot be saved in grid view when configuring the 2nd UOM 
related to defect 0023136 closedshankarb Quantity field behaves differently in Sales Order Line and Purchase Order Line 
related to defect 00230563.0MP21 closedshankarb Ordered Quantiy field of Sales Order is not properly auto filling the grouping separator 
related to defect 00284273.0PR15Q2 closedAugustoMauch Price is not rounded to calculate the line net amount in Create Lines process of Purchase Order 
related to defect 0020474 closedmtaal When you save a register in grid view, amounts fields change to the previous value 
related to defect 00255173.0PR14Q3 closedshankarb Wrong calculations on numeric field depending on the formula 
related to defect 0032051 acknowledgedplatform review and remove occurrences of new BigDecimal(double) 
related to defect 0032668 closedalostale Wrong Total Gross Amount, Total Net Amount and Tax information is obtained in order and invoices 
causes defect 00322023.0PR16Q2 closedcaristu Error in add payment when editing the amount of a record in order/invoice grid 

-  Notes
alostale (developer)
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.
caristu (developer)
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

hgbot (developer)
2016-01-25 18:50

Repository: erp/devel/pi
Changeset: 69d968879453d377cda8501a1cf0a6c9772d3693
Author: Carlos Aristu <carlos.aristu <at>>
Date: Mon Jan 25 18:46:51 2016 +0100
URL: [^]

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/
alostale (developer)
2016-01-29 08:57

code reviewed

tested related issues
hudsonbot (developer)
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: [^]
Maturity status: Test

- Issue History
Date Modified Username Field Change
2016-01-14 23:30 rbianchini New Issue
2016-01-14 23:30 rbianchini Assigned To => platform
2016-01-14 23:30 rbianchini File Added: evenhandler.tar.gz
2016-01-14 23:30 rbianchini Modules => Core
2016-01-14 23:30 rbianchini Resolution time => 1453431600
2016-01-14 23:30 rbianchini Triggers an Emergency Pack => No
2016-01-15 13:27 alostale Note Added: 0083351
2016-01-15 13:27 alostale Assigned To platform => rbianchini
2016-01-15 13:27 alostale Status new => feedback
2016-01-18 21:28 rbianchini Assigned To rbianchini => alostale
2016-01-18 21:28 rbianchini Status feedback => new
2016-01-18 21:29 rbianchini Steps to Reproduce Updated View Revisions
2016-01-19 11:07 alostale Resolution time 1453431600 => 1453417200
2016-01-19 11:07 alostale Summary Error in Event Handler's event.currentState => can't change by trigger/observer manually edited decimal value in form
2016-01-19 11:07 alostale Description Updated View Revisions
2016-01-19 11:07 alostale Steps to Reproduce Updated View Revisions
2016-01-19 11:07 alostale File Added: org.openbravo.platform.issues-0.0.0.obx
2016-01-19 11:09 alostale Relationship added related to 0016789
2016-01-19 11:09 alostale Relationship added related to 0016818
2016-01-19 11:10 alostale Relationship added related to 0029092
2016-01-19 11:10 alostale Relationship added related to 0031404
2016-01-19 11:10 alostale Relationship added related to 0031189
2016-01-19 11:12 alostale Relationship added related to 0022025
2016-01-19 11:14 alostale Summary can'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:20 alostale Status new => scheduled
2016-01-19 12:20 alostale Assigned To alostale => caristu
2016-01-25 12:49 caristu Relationship added related to 0023136
2016-01-25 12:50 caristu Relationship added related to 0023056
2016-01-25 12:51 caristu Relationship added related to 0028427
2016-01-25 12:52 caristu Relationship added related to 0020474
2016-01-25 17:09 caristu Relationship added related to 0025517
2016-01-25 17:41 caristu Note Added: 0083593
2016-01-25 17:48 caristu Note Edited: 0083593 View Revisions
2016-01-25 18:50 caristu Review Assigned To => alostale
2016-01-25 18:50 caristu Assigned To caristu => alostale
2016-01-25 18:50 hgbot Checkin
2016-01-25 18:50 hgbot Note Added: 0083595
2016-01-25 18:50 hgbot Status scheduled => resolved
2016-01-25 18:50 hgbot Resolution open => fixed
2016-01-25 18:50 hgbot Fixed in SCM revision => [^]
2016-01-25 19:05 caristu Issue Monitored: alostale
2016-01-26 10:59 caristu Assigned To alostale => caristu
2016-01-29 08:57 alostale Note Added: 0083707
2016-01-29 08:57 alostale Status resolved => closed
2016-01-29 08:57 alostale Fixed in Version => 3.0PR16Q2
2016-01-29 09:04 alostale Relationship added related to 0032051
2016-02-11 15:45 caristu Relationship added causes 0032202
2016-03-17 10:55 hudsonbot Checkin
2016-03-17 10:55 hudsonbot Note Added: 0085080
2016-04-26 08:42 alostale Relationship added related to 0032668

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker