Openbravo Issue Tracking System - Openbravo ERP |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0010941 | Openbravo ERP | Z. Others | public | 2009-10-13 10:44 | 2009-10-23 00:01 |
|
| Reporter | shuehner | |
| Assigned To | harikrishnan | |
| Priority | immediate | Severity | critical | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | |
| Platform | | OS | 5 | OS Version | |
| Product Version | pi | |
| Target Version | | Fixed in Version | | |
| Merge Request Status | |
| Review Assigned To | |
| OBNetwork customer | |
| Web browser | |
| Modules | Core |
| Support ticket | |
| Regression level | |
| Regression date | |
| Regression introduced in release | |
| Regression introduced by commit | |
| Triggers an Emergency Pack | No |
|
| Summary | 0010941: API check build 171 fails - part2 |
| Description | This api check build failed:
http://builds.openbravo.com/job/erp_devel_pi-module-integrity-test/171/console [^]
These issues are tracked here:
org.openbravo.model.common.currency:
Bad
method org.openbravo.model.common.currency.ConversionRate.getDivideRateBy(): type java.lang.Float in api-checks/java/reference/250, but type java.math.BigDecimal in /var/www/localhost/htdocs/japi/171
method org.openbravo.model.common.currency.ConversionRate.getMultipleRateBy(): type java.lang.Float in api-checks/java/reference/250, but type java.math.BigDecimal in /var/www/localhost/htdocs/japi/171
Missing
method org.openbravo.model.common.currency.ConversionRate.setDivideRateBy(java.lang.Float): missing in /var/www/localhost/htdocs/japi/171
method org.openbravo.model.common.currency.ConversionRate.setMultipleRateBy(java.lang.Float): missing in /var/www/localhost/htdocs/japi/171
|
| Steps To Reproduce | |
| Proposed Solution | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | | related to | defect | 0010574 | 2.40MP10 | closed | harikrishnan | The converion rate table has to save the rates with more decimals | | related to | feature request | 0011033 | | new | iciordia | API checks on minor versions of modules |
|
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2009-10-13 10:44 | shuehner | New Issue | |
| 2009-10-13 10:44 | shuehner | Assigned To | => rafaroda |
| 2009-10-13 10:46 | shuehner | Note Added: 0020968 | |
| 2009-10-13 10:46 | shuehner | Relationship added | related to 0010574 |
| 2009-10-13 10:46 | shuehner | Assigned To | rafaroda => jeneivemalarkodi |
| 2009-10-14 19:25 | vmromanos | Note Added: 0021017 | |
| 2009-10-15 11:57 | jeneivemalarkodi | Note Added: 0021033 | |
| 2009-10-16 13:51 | psarobe | Issue Monitored: pjuvara | |
| 2009-10-16 13:51 | psarobe | Note Added: 0021113 | |
| 2009-10-16 13:51 | psarobe | Status | new => feedback |
| 2009-10-20 18:31 | dmitry_mezentsev | Note Added: 0021226 | |
| 2009-10-20 19:13 | vmromanos | Note Added: 0021228 | |
| 2009-10-20 19:47 | dmitry_mezentsev | Note Added: 0021232 | |
| 2009-10-21 09:03 | hgbot | Checkin | |
| 2009-10-21 09:03 | hgbot | Note Added: 0021242 | |
| 2009-10-21 09:03 | hgbot | Status | feedback => resolved |
| 2009-10-21 09:03 | hgbot | Resolution | open => fixed |
| 2009-10-21 09:03 | hgbot | Fixed in SCM revision | => http://code.openbravo.com/erp/devel/pi/rev/8000c4d08283e3653847808b95e6fee55a5dd024 [^] |
| 2009-10-21 10:34 | vmromanos | Note Added: 0021249 | |
| 2009-10-22 09:05 | psarobe | Status | resolved => closed |
| 2009-10-22 10:28 | dmitry_mezentsev | Relationship added | related to 0011033 |
| 2009-10-22 10:31 | rafaroda | Assigned To | jeneivemalarkodi => harikrishnan |
| 2009-10-23 00:01 | anonymous | sf_bug_id | 0 => 2884258 |
|
Notes |
|
|
|
Change is most likely introduced by this changeset:
changeset: 5205:39e29fcb1883
user: Jeneive malarkodi <jeneive.malarkodi@openbravo.com>
date: Thu Oct 08 19:17:48 2009 +0530
files: src-db/database/sourcedata/AD_COLUMN.xml
description:
Fixed Issue 10574: The conversion rate table with more decimals |
|
|
|
|
|
Warning: this change has broken a module I developed some months ago (Invoice Register Book). Now I am unable to compile it. |
|
|
|
|
Reg. Issue 0010574
Dear Paolo,
This issue is regarding to increase the size of the field, conversion
Rate. After deep reviews, rafa has came into the solution to change the
reference type, from number to 'General Quantity'. kindly review the
discussions in the Issue 'Notes'.
As per the proposed solution I have changed the reference Type. Kingly
approve this issue to change in API.
Thanks & Regards,
Jeneive Malar Kodi V |
|
|
|
|
|
Reminder sent to: pjuvara
Paolo, your call |
|
|
|
|
Discussion is still underway about reverting this change if we have a better and not very painful option to fix this issue in core.
Reverting changes should not affect our SLA´s cause we can leave current fix in 2.40 where it was reported for this customer but fix it in a better way in 2.50.
If the effort is huge we can change our SPLP modules and I hope it should not affect others cause we do not have lots of modules now... |
|
|
|
|
Dmitry,
The effort of changing the Invoice Register Book module is minimum, but take into account two things:
1- If we change core's API we must change also the IRB, and people could not update in the future to new IRB versions unless they update also the MP. It is a very strange case, but maybe someone doesn't want to update the MP and it's using the IRB.
2- If we change core's API we must release the new version of the IRB at the same time (or before) the new MP with the API change is released, otherwise the module won't work while the user doesn't have installed the last version of both the module and core. |
|
|
|
|
Victor,
Yes, the first case is really strange - if the user does not want to update to the proper MP than sorry he/her won´t have new version of the report.
The second one is definitely more serious and I think that if we decide to follow this way (hope not) we will need to communicate it properly through the MP Release Notes notifying explicitly that this module will require update.
For the future IMHO we also need to think about automatic check of the compatibility of installed modules and new core and notify users before the upgrade that some modules will stop working or will require update after it to behave properly (and maybe even install these updates automatically if the user agrees).
I guess something similar is in Ismael´s roadmap. |
|
|
|
(0021242)
|
|
hgbot
|
|
2009-10-21 09:03
|
|
|
|
|
|
Dmitry,
I totally agree with you. In fact the things you're talking about remember me two bugs I have recently reported: 0010999 and 0011033 |
|