|
Notes |
|
|
|
|
The removal of a column from the unique-constraint makes it more strict, which could make it fail for existing data. |
|
|
|
|
This api change is related to the fixing of the issue 12589. In 12589, the constraint C_BP_VENDOR_ACCT_ACCTSCHEMA_UN in the table C_BP_VENDOR_ACCT includes the following columns C_ACCTSCHEMA_ID, C_BPARTNER_ID, STATUS and AD_ORG_ID. so, the system allows to create two vendor accounting lines using same account schema with different organization. So, the AD_ORG_ID is removed from the constraint not allow to create such that.
In order to fix this api break, i need a confirmation whether this api change is valid or not. |
|
|
|
|
This api change is related to the fixing of the issue 12589. In 12589, the constraint C_BP_VENDOR_ACCT_ACCTSCHEMA_UN in the table C_BP_VENDOR_ACCT includes the following columns C_ACCTSCHEMA_ID, C_BPARTNER_ID, STATUS and AD_ORG_ID. so, the system allows to create two vendor accounting lines using same account schema with different organization. So, the AD_ORG_ID is removed from the constraint not allow to create such that.
In order to fix this api break, i need a confirmation whether this api change is valid or not. |
|
|
|
|
@paolo:
The problem with that issue is that there might be local data, which is not fine with the new changed/stricter constraint.
Using the new BuildValidation project (will be included in MP15, see [1]) we can add a check if the data is fine, and if not stop the upgrade with a error message explaining what/why and what needs to be checked/changed in the local system.
If we add this validation, then it should be fine to accept this changed constraint.
[1] http://wiki.openbravo.com/wiki/Projects/ValidationsAndPrescripts [^] |
|
|
|
|
The proposed constraint change is certainly correct functionally (it mirrors the customer account constraints) but I understand shuehner's concern on update for existing customers.
Can we postpone the fix for issue 12589 till after MP15 so that we can add a validation script prompting users to clean up the data before applying the update? |
|
|
|
|
Hi
As Stefan mentioned, the Build Validations will be included in MP15 (the project was already merged to pi), so there is no problem afaics in including both the API change and the validation now, as everything should be fine (in the validation we can include a specific message telling the users what they should do). |
|
|
|
|
|
I am OK with marvintm suggestion. |
|
|
|
(0026042)
|
|
hgbot
|
|
2010-04-09 18:38
|
|
Repository: erp/devel/pi
Changeset: 5c592e20669af9595f420264548768f1bc6e7248
Author: David Alsasua <david.alsasua <at> openbravo.com>
Date: Fri Apr 09 18:50:30 2010 +0200
URL: http://code.openbravo.com/erp/devel/pi/rev/5c592e20669af9595f420264548768f1bc6e7248 [^]
Fixes issue 12824: api check build 327
---
M src-db/database/sourcedata/AD_MESSAGE.xml
A src-util/buildvalidation/src/org/openbravo/buildvalidation/Cbpvendoracct.java
A src-util/buildvalidation/src/org/openbravo/buildvalidation/Cbpvendoracct_data.xsql
---
|
|
|
|
(0026043)
|
|
hgbot
|
|
2010-04-09 18:51
|
|
|
|
|
(0026044)
|
|
hgbot
|
|
2010-04-09 19:05
|
|
Repository: erp/devel/pi
Changeset: 6c78ad9d51765ab3f499895fae814e7bf27da3af
Author: David Alsasua <david.alsasua <at> openbravo.com>
Date: Fri Apr 09 19:17:41 2010 +0200
URL: http://code.openbravo.com/erp/devel/pi/rev/6c78ad9d51765ab3f499895fae814e7bf27da3af [^]
Fixes issue 12824: api check build 327
---
A src-util/buildvalidation/build/classes/org/openbravo/buildvalidation/Cbpvendoracct.class
A src-util/buildvalidation/build/classes/org/openbravo/buildvalidation/CbpvendoracctData.class
---
|
|
|
|
|
|
api-check build now fine -> closing |
|
|
|
|
|
|
|
|
|