int-api - Build # 1054 - Still Failing:
Check console output at https://ci.openbravo.com/job/int-api/1054/ to view the
results.
Committers since last success:
Changes for Build #1051
RM packaging bot [email protected]_ null
Merge back from main
RM packaging bot [email protected]_ null
Added signature for changeset 53cc6ea75bb1
.hgsigs
RM packaging bot [email protected]_ null
Added tag 3.0PR14Q4 for changeset ed3565630685
.hgtags
RM packaging bot [email protected]_ null
Update AD_MODULE version to 3.0PR14Q4
modules/org.openbravo.advpaymentmngt/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.advpaymentmngt/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.base.weld/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.base.weld/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.client.application/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.client.application/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.client.htmlwidget/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.client.htmlwidget/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.client.kernel/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.client.kernel/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.client.myob/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.client.myob/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.client.querylist/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.client.querylist/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.client.widgets/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.client.widgets/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.financial.paymentreport/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.financial.paymentreport/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.reports.ordersawaitingdelivery/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.reports.ordersawaitingdelivery/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.service.datasource/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.service.datasource/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.service.integration.google/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.service.integration.google/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.service.integration.openid/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.service.integration.openid/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.service.json/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.service.json/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.userinterface.selector/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.userinterface.selector/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.userinterface.skin.250to300Comp/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.userinterface.skin.250to300Comp/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.userinterface.smartclient/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.userinterface.smartclient/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.v3.datasets/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.v3.datasets/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.v3.framework/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.v3.framework/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
modules/org.openbravo.v3/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.v3/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml
src-db/database/sourcedata/AD_MODULE.xml
Asier Lostalé [email protected]_ null
fixed bug 28386: keep selected item when reopening FK drop down
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/form/formitem/ob-formitem-fk-filter.js
Asier Lostalé [email protected]_ null
fixed bug 28386: FK filter dropdown hides elements when it's reopened
When a FK filter drop down was reopened after having selected an element, it
only displayed that element in the list.
Few things have been fixed:
* When requesting datasource for FK drop down, the same criteria used in the
grid is used, but removing that drop down criterion. This was not properly
done for direct FK selection
* == element before the identifier was some times removed
* When reopening a drop down having an element selected, the criteria was
changed
from equals with FK value to iEquals with identifier value
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/form/formitem/ob-formitem-fk-filter.js
Alvaro Ferraz [email protected]_ null
Fixes bug 28308 LandedCost Accounting should always be created in the same
order
In order to help JUnit tests assert landed cost accounting, an orderBy clause
has been added when creating Landed Cost Accounting lines, to be created always
in the same order
src/org/openbravo/erpCommon/ad_forms/DocLineLandedCost_data.xsql
Alvaro Ferraz [email protected]_ null
Fixes bug 28266 ParentCostAdjustmentLine should always be assigned in the
same order
In order to help JUnit tests assert Cost Adjustment lines, an orderBy clause
has been added when assigning the field "Parent Cost Adjustment Line" to follow
always the same order
src/org/openbravo/costing/CostAdjustmentProcess.java
Alvaro Ferraz [email protected]_ null
Related to Issue 28148 Cost Adjustment Lines created ordered by
trxprocessdate
In order to help JUnit tests assert Cost Adjustment lines, an orderBy clause
has been added when creating cost adjustment lines of type Landed Cost to
follow always the same order
src/org/openbravo/costing/LCMatchingProcess.java
Alvaro Ferraz [email protected]_ null
Related to bug 28286 LandedCostLineAmt should always be created in the same
order
The field in the order by clause must appear in the group by clause to prevent
fail in Postgresql 8.4
src/org/openbravo/costing/LandedCostDistributionByAmount.java
Alvaro Ferraz [email protected]_ null
Fixes bug 28286 LandedCostLineAmt should always be created in the same order
In order to help JUnit tests assert landed cost, an orderBy clause has been
added when creating Landed Cost Receipt Line Amount lines, to be always created
in the same order.
src/org/openbravo/costing/LandedCostDistributionByAmount.java
src/org/openbravo/costing/LandedCostProcess.java
Alvaro Ferraz [email protected]_ null
Fixes bug 28387 BillofMaterialsAccounting should always be created in the
same order
In order to help JUnit tests assert Bill of Materials Production accounting, an
orderBy clause has been added when creating Bill of Materials Production
Accounting lines, to be created always in the same order
src/org/openbravo/erpCommon/ad_forms/DocLineProduction_data.xsql
Alvaro Ferraz [email protected]_ null
[Costing]Related to issue 28333 Data needed in demodata for CostAdjustment
test
referencedata/sampledata/QA_Testing/M_LANDEDCOST.xml
referencedata/sampledata/QA_Testing/M_LC_COST.xml
referencedata/sampledata/QA_Testing/AD_SEQUENCE.xml
Alvaro Ferraz [email protected]_ null
[Costing]Related to issue 28333 Data needed in demodata for CostAdjustment
test
Enable M_LandedCost, M_LC_Cost and M_LC_Type tables in sampledata dataset
src-db/database/sourcedata/AD_DATASET_TABLE.xml
Alvaro Ferraz [email protected]_ null
[Costing] Fixes issue 28333: Data needed in demodata for CostAdjustment test
referencedata/sampledata/QA_Testing/C_GLITEM_ACCT.xml
referencedata/sampledata/QA_Testing/M_LC_TYPE.xml
referencedata/sampledata/QA_Testing/AD_ORG_WAREHOUSE.xml
referencedata/sampledata/QA_Testing/AD_PREFERENCE.xml
referencedata/sampledata/QA_Testing/AD_PROCESS_REQUEST.xml
referencedata/sampledata/QA_Testing/AD_SEQUENCE.xml
referencedata/sampledata/QA_Testing/C_BPARTNER.xml
referencedata/sampledata/QA_Testing/C_BPARTNER_LOCATION.xml
referencedata/sampledata/QA_Testing/C_BP_CUSTOMER_ACCT.xml
referencedata/sampledata/QA_Testing/C_BP_VENDOR_ACCT.xml
referencedata/sampledata/QA_Testing/C_DOCTYPE.xml
referencedata/sampledata/QA_Testing/C_GLITEM.xml
referencedata/sampledata/QA_Testing/C_LOCATION.xml
referencedata/sampledata/QA_Testing/C_ORDER.xml
referencedata/sampledata/QA_Testing/C_ORDERLINE.xml
referencedata/sampledata/QA_Testing/C_ORDERLINETAX.xml
referencedata/sampledata/QA_Testing/C_ORDERTAX.xml
referencedata/sampledata/QA_Testing/M_LOCATOR.xml
referencedata/sampledata/QA_Testing/M_PRICELIST.xml
referencedata/sampledata/QA_Testing/M_PRICELIST_VERSION.xml
referencedata/sampledata/QA_Testing/M_PRODUCT.xml
referencedata/sampledata/QA_Testing/M_PRODUCTPRICE.xml
referencedata/sampledata/QA_Testing/M_PRODUCT_ACCT.xml
referencedata/sampledata/QA_Testing/M_WAREHOUSE.xml
referencedata/sampledata/QA_Testing/M_WAREHOUSE_ACCT.xml
Unai Martirena [email protected]_ null
Fixes Issue 28450: Costing Migration Process does not fail any more.
In the function insertTrxCosts() in CostingMigrationProcess.java while
inserting m_transaction_cost records the column dateacct is filled in the
following way:
* If the transaction is a goods shipment line, with the accounting date of the
Shipment.
* If the transaction is not a goods shipment line, with the movement date of
the transaction.
src/org/openbravo/costing/CostingMigrationProcess.java
Unai Martirena [email protected]_ null
Fixes Bug 28441:Validate Costing Rule doesn't fail if there prev
transactions.
The process was failing while trying to create Transaction Cost records in
initializeOldTrx and updateInventoriesCostAndProcessInitInventories processes.
It was not setting any value to accounting date column, which is mandatory.
This column has been populated in the following way: If the related transaction
is a shipment the accounting date of the shipment is assigned, if not, the
movement date of the transaction will be assigned.
src/org/openbravo/costing/CostingRuleProcess.java
Unai Martirena [email protected]_ null
Fixes bug 28401:Initialized All Trx process not uses movement date.
Initialize Old Transaction process inside Validate Costing Rule process should
filter by Movement Date of Transactions instead of Transaction Process Date
src/org/openbravo/costing/CostingRuleProcess.java
Unai Martirena [email protected]_ null
Related to issue 28289: Improve @FixBackdateFromBeforeStartingDate@ message
src-db/database/sourcedata/AD_MESSAGE.xml
Unai Martirena [email protected]_ null
Related to bug 28289:Do @FixBackdateFromBeforeStartingDate@ later in the
process.
Check the validation at the end of the Costing Rule Validation process when
fixbackdated from and starting date are being initialized.
Also update the error message displayed.
src-db/database/sourcedata/AD_MESSAGE.xml
src/org/openbravo/costing/CostingRuleProcess.java
Unai Martirena [email protected]_ null
Related to issue 28289: Little code review
src/org/openbravo/costing/CostingRuleProcessActionHandler.java
src/org/openbravo/costing/CostingRuleProcessOnProcessHandler.java
src/org/openbravo/costing/CostingUtils.java
Unai Martirena [email protected]_ null
Fixes Bug 28289: Manage null start and fix backdated from dates in Costing
Rule.
Several things have been implemented in this changeset:
* A new Process Definition called 'Validate Costing Rule' has been created that
replaces the old Process with the same name. This has been done to be able to
use the new capabilities that these new kind of processes offer, like
validations before executing the process and the posibility to show a
confirmation popup. The new process action handler calls the old process java
class, so all existing modules that may call or extend the old class they will
continue working.
* The CostingRuleEventHandler has been removed, because it was doing a wrong
validation and the fix backdated from date is managed in the CostingRuleProcess.
* 2 new functions have been created in CostingUtils
('getCostingRuleStartingDate' and 'getCostingRuleFixBackdatedFrom') that they
return '01/01/1900' as costing rule Starting Date or Fix Backdated From when
these are null. This has been done because in some places when these dates are
null the application was giving an error. So, every time these dates are
retrieved, these functions will be called.
* A validation has been added before executing the new Action Handler 'Validate
Costing Rule' that shows a popup when transactions without cost calculated are
found in closed periods. It asks for confirmation to proceed or the option to
cancel.
src/org/openbravo/costing/CostingRuleProcessActionHandler.java
src/org/openbravo/costing/CostingRuleProcessOnProcessHandler.java
web/js/validateCostingRuleProcess.js
modules/org.openbravo.client.application/src/org/openbravo/client/application/ApplicationComponentProvider.java
referencedata/sampledata/F_B_International_Group/AD_PROCESS_ACCESS.xml
referencedata/sampledata/F_B_International_Group/OBUIAPP_PROCESS_ACCESS.xml
referencedata/sampledata/QA_Testing/AD_PROCESS_ACCESS.xml
referencedata/sampledata/QA_Testing/OBUIAPP_PROCESS_ACCESS.xml
src-db/database/sourcedata/AD_COLUMN.xml
src-db/database/sourcedata/AD_ELEMENT.xml
src-db/database/sourcedata/AD_MESSAGE.xml
src-db/database/sourcedata/AD_MODEL_OBJECT.xml
src-db/database/sourcedata/AD_PROCESS.xml
src-db/database/sourcedata/OBUIAPP_PROCESS.xml
src/org/openbravo/costing/AverageCostAdjustment.java
src/org/openbravo/costing/CostAdjustmentUtils.java
src/org/openbravo/costing/CostingAlgorithmAdjustmentImp.java
src/org/openbravo/costing/CostingRuleProcess.java
src/org/openbravo/costing/CostingServer.java
src/org/openbravo/costing/CostingUtils.java
src/org/openbravo/costing/FixBackdatedTransactionsProcess.java
src/org/openbravo/costing/StandardAlgorithm.java
src/org/openbravo/costing/StandardCostAdjustment.java
src/org/openbravo/event/CostingRuleEventHandler.java
Unai Martirena [email protected]_ null
Fixes Bug 28289:Add Starting Date and Fix Backdated From allways to Costing
Rule
Modify CostingRuleEventHandler.java to allways set an Starting Date and Fix
Backdated From to a Costing Rule if it has not been added manually. Take as
Starting Date the Starting Date of the first period that is opened. Set the
same date as Fix Backdated From.
src/org/openbravo/event/CostingRuleEventHandler.java
Unai Martirena [email protected]_ null
Related to Issue 28301: Fix on updateBDCostingTimeRange function.
If the movement date of the inventory transaction related to current costing
record is before the movement date of the inventory transaction related to
backdated costing record, then the backdated costing record would be the
current costing record. In other case the current costing record would remain
as current costing record.
src/org/openbravo/costing/AverageCostAdjustment.java
Unai Martirena [email protected]_ null
Fixes Issue 28301: Cost is properly calculated after two backdated
transactions.
The problem was in updateBDCostingTimeRange function. While updating the
backdated average costing time, if a previous costing record was found, the
future ending date was assigned to backdated costing record, not to the current
costing, leaving as current costing the backdated costing record, and this is
wrong.
src/org/openbravo/costing/AverageCostAdjustment.java
Unai Martirena [email protected]_ null
Related to bug 28389: If is no diff in match LCC leave LCC amount as
matchedAmt
src/org/openbravo/costing/LandedCostProcess.java
Unai Martirena [email protected]_ null
Related to Issue 28389: Fixed Posting of LC Cost with Invoice Line
While processing a Landed Cost with an Invoice in a Landed Cost Cost it, if the
invoice has an exchange rate different from the system, a new Cost Adjustment
is created with that difference between the rates. But this difference it was
not taking into account while setting the matched amount in Landed Cost Cost,
so the Post process it was not working well.
src/org/openbravo/costing/LandedCostProcess.java
Miguel A. Alsasua [email protected]_ null
fixed issue 28389: the difference amount is calculated adding the amount of
all lines
the difference amount between the cost amount and matched amount was wrong
calculated when there was more than one line in landed cost cost tab
src/org/openbravo/erpCommon/ad_forms/DocLCCost.java
Unai Martirena [email protected]_ null
Fixes issue 28192: Net Unit Price now is properly calculated.
In order to calculate the Net Unit Price, the adjustments of the transaction
are used, but it was not being used the signMultiplier of the transaction, and
needs to be used.
src/org/openbravo/costing/AverageCostAdjustment.java
Unai Martirena [email protected]_ null
Fixes Issue 28157: Landed Cost takes into account exchange rate at invoice
level
If an exchange rate different from the System is added in Purchase Invoice and
this Invoice is matched in a Landed Cost, a new record will be created in
'Matched Amount' tab under 'Landed Cost Cost' tab of 'Landed Cost' window. This
new record will have the new flag of 'Is Conversion Matching' as true, and the
amount will be the difference obtained from using the Invoice exchange rate
compared to the one of the System.
This will create a new Cost Adjustment of source 'Landed Cost' with the same
amount.
src-db/database/model/tables/M_LC_MATCHED.xml
src-db/database/sourcedata/AD_COLUMN.xml
src-db/database/sourcedata/AD_ELEMENT.xml
src-db/database/sourcedata/AD_FIELD.xml
src/org/openbravo/common/inserters/LCMatchFromInvoiceInserter.java
src/org/openbravo/costing/LCCostMatchFromInvoiceHandler.java
src/org/openbravo/costing/LandedCostProcess.java
Unai Martirena [email protected]_ null
Related to Issue 28113: Revert a change on issue 28115.
In this cases the net unit price is the cost of the transaction
src/org/openbravo/costing/AverageCostAdjustment.java
Alvaro Ferraz [email protected]_ null
Fixes bug 28230 Null Pointer Exception is raised when trying to post a
goods receipt
When a goods receipt with a product of type Service, which has a cost of type
Standard, is posted, the DocInOut class calls the getStandardCost method from
CostingUtils class with the currency of the current organization. If the
organization has no currency, the client's currency will be used. Otherwise, a
null pointer exception will be raised.
src/org/openbravo/erpCommon/ad_forms/DocInOut.java
src/org/openbravo/erpCommon/ad_forms/DocMatchInv.java
Unai Martirena [email protected]_ null
Fixes Issue 28234: Check in Costing Rule Validation that the org has
Currency.
If the organization has no currency defined, the costing process will use the
currency defined in the client. This could be wrong if the currency for the
transactions of this organization should be different that the currency of the
client, so before validating a costing rule the organization of it should have
a currency defined.
src-db/database/sourcedata/AD_MESSAGE.xml
src/org/openbravo/costing/CostingRuleProcess.java
Unai Martirena [email protected]_ null
Related to Issue 28238: Clear Goods Shipment Lines when changing Goods
Shipment.
A callout has been implemented in Goods Shipment field.
src/org/openbravo/erpCommon/ad_callouts/SL_LandedCost_Receipt.java
src-db/database/sourcedata/AD_CALLOUT.xml
src-db/database/sourcedata/AD_COLUMN.xml
src-db/database/sourcedata/AD_MODEL_OBJECT.xml
src-db/database/sourcedata/AD_MODEL_OBJECT_MAPPING.xml
Unai Martirena [email protected]_ null
Fixes Issue 28238: Cost Adjustment of Landed Cost type properly created.
Receipt tab of Landed Cost has been designed to work in the following way:
* either a Goods Receipt header is selected in 'Goods Receipt' field -> this
option implies that specified landed cost are distributed among all Goods
Receipt lines.
* or a Goods Receipt header is selected in Goods Receipt field and a Goods
Receipt line 'of the very same Goods Receipt' is selected in the field 'Goods
Receipt Line' -> this option implies that specified landed cost are distribute
just for the Goods receipt line selected.
Above behaviour implies that Goods Receipt lines field lists only goods receipt
lines of the goods receipt selected in Goods Receipt field. In order to do this
a where clause has been added in Goods Receipt Lines selector to only display
lines of the selected header, if no header is selected, no lines would be
displayed.
src-db/database/sourcedata/OBUISEL_SELECTOR.xml
Sandra Huguet [email protected]_ null
Fixed bug 28362 c_invoice_post creates unnecesary contentions
Avoiding the join with m_pricelist and c_doctype contentions are solved
src-db/database/model/functions/C_INVOICE_POST.xml
Sandra Huguet [email protected]_ null
Fixed bug 28360 c_order_post creates unnecesary contentions
Avoiding the join with m_pricelist the m_pricelist contention is solved
For update sentence is deleted in c_orderline selects because the
c_orderline is bloqued with the main select and is redundant and
causes unnecessary contentions.
src-db/database/model/functions/C_ORDER_POST1.xml
Augusto Mauch [email protected]_ null
Fixed issue 28242: Load grid even with inconsistent default view info
Before the previous changeset was applied, it was possible to have a preference
that specified that a certain grid had a default saved view, but that the
referenced default saved view did not actually exists. When this happened the
grid was not loaded until the user pressed the Refresh button.
To fix this, now the inconsistent default view info is detected and the grid is
loaded once it is detected that the default view does not actually exists.
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/main/ob-standard-view.js
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/main/ob-standard-window.js
Augusto Mauch [email protected]_ null
Related with issue 28242: Delete preference along with window
personalization
When a grid view is saved and set as default two records are added:
- One to the OBUIAPP_UIPersonalization with the description of the view
- One to the Preference table, using the OBUIAPP_DefaultSavedView property,
whose value is the ID of the record added to the OBUIAPP_UIPersonalization table
The problem of this issue was that when the a default saved view was removed
from the OBUIAPP_UIPersonalization table, its corresponding entry from the
Preference table was not removed. This resulted in not making the initial
request to load the grid because it was detected that the view had a default
saved view (using the preference), and not doing it after loading the window
personalization because the view description was removed from
OBUIAPP_UIPersonalization.
The first step of the issue, included in this changeset, removes the Preference
associated with a default saved view when it is deleted from
OBUIAPP_UIPersonalization. This prevents the data from being inconsistent. The
second and final step will consist in loading the grid even when the data is
inconsistent, to fix the cases where the data is already inconsistent.
modules/org.openbravo.client.application/src/org/openbravo/client/application/event/WindowPersonalizationEventHandler.java
Atul Gaware [email protected]_ null
Fixes Issues 27820:Error when posting Payment/Transaction/Reconciliation
referencing a cash vat invoice linked to several orders
Issue is a regression due to related fix for issue 26571. Cast Vat lines
were posted as many times the no. of orders linked with cash vat invoices.
So now posting is based on the payment details so the relevant cash vat line
associated with it is posted though it is looped as many times as the no. of
orders linked.
src/org/openbravo/erpCommon/ad_forms/DocFINFinAccTransaction.java
src/org/openbravo/erpCommon/ad_forms/DocFINPayment.java
src/org/openbravo/erpCommon/ad_forms/DocFINReconciliation.java
src/org/openbravo/erpCommon/ad_forms/DocLineCashVATReady_PaymentTransactionReconciliation.java
Changes for Build #1052
Augusto Mauch [email protected]_ null
Fixes issue 28501: Window is property loaded having read only tabs
There was a problem in the way read only tabs were initialized. It was caused
by this changeset [1], which fixed a problem related with read only tabs loaded
lazily. The problem is that under some circumstances the setReadOnly function
of the standard view was called without it being fully initialized. The
setReadOnly invokation ended up calling the OBViewGrid.resetEmptyMessage
function, and tried to execute this line:
this.view.parentView.isShowingTree
The problem is that the parentView property of the view was not set yet, so an
error was thrown. To fix this, now the code to update some view properties
based in its uiPattern value is executed after the parentView property is
properly set.
[1]
https://code.openbravo.com/erp/devel/pi/rev/052c07be4a9ddd2b2a61bd60e948370c53482cb4
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/main/ob-standard-view.js
Changes for Build #1053
Sandra Huguet [email protected]_ null
Related to issue 27580 fixed issue to cash vat invoices
src/org/openbravo/erpCommon/ad_forms/DocInvoice.java
Changes for Build #1054
Sandra Huguet [email protected]_ null
Related to issue 27580 fixed issue to cash vat purchase invoices
src/org/openbravo/erpCommon/ad_forms/DocInvoice.java
Last 20 lines of the console output:
[...truncated 27902 lines...]
method
org.openbravo.model.financialmgmt.payment.FIN_Reconciliation.getAPRMRecDetailVList():
missing in /srv/ci/workspace/int-full-pgsql/SANDBOX/api-checks/output/java
method
org.openbravo.model.financialmgmt.payment.FIN_Reconciliation.getWidget():
missing in /srv/ci/workspace/int-full-pgsql/SANDBOX/api-checks/output/java
method
org.openbravo.model.financialmgmt.payment.FIN_Reconciliation.setAPRMRecDetailVList(java.util.List<org.openbravo.advpaymentmngt.ReconciliationDetail>):
missing in /srv/ci/workspace/int-full-pgsql/SANDBOX/api-checks/output/java
method
org.openbravo.model.financialmgmt.payment.FIN_Reconciliation.setWidget(java.lang.String):
missing in /srv/ci/workspace/int-full-pgsql/SANDBOX/api-checks/output/java
+ failure=1
+ exit 1
Build step 'Execute shell' marked build as failure
Performing Post build task...
Match found for : : True
Logical operation result is TRUE
Running script : cp
/srv/ci/workspace/int-full-pgsql/SANDBOX/api-checks/output/java.japi.gz .
[int-api] $ /bin/bash -xe /tmp/hudson7027496170401691280.sh
+ cp /srv/ci/workspace/int-full-pgsql/SANDBOX/api-checks/output/java.japi.gz .
POST BUILD TASK : SUCCESS
END OF POST BUILD TASK : 0
Archiving artifacts
Checking console output
Email was triggered for: Failure
Sending email for trigger: Failure
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Openbravo-builds mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openbravo-builds
