int-initial-pgsql - Build # 948 - Unstable:
Check console output at https://ci.openbravo.com/job/int-initial-pgsql/948/ to
view the results.
Committers since last success:
Changes for Build #948
RM packaging bot <[email protected]> null
Merge back from main
RM packaging bot <[email protected]> null
Merge temporary head for 3.0PR15Q2.1
RM packaging bot <[email protected]> null
Added signature for changeset fdb1e0cd936d
.hgsigs
RM packaging bot <[email protected]> null
Added tag 3.0PR15Q2.1 for changeset e861122b0b1d
.hgtags
RM packaging bot <[email protected]> null
Update AD_MODULE version to 3.0PR15Q2.1
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.utility.cleanup.log/src-db/database/sourcedata/AD_MODULE.xml
modules/org.openbravo.utility.cleanup.log/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
Víctor Martínez Romanos <[email protected]> null
Fixed bug 29808: Impossible to create several calendars for the same
organization
Two pieces of code were affected by this bug:
PeriodEventHandler.java: EntityPersistenceEventObserver in charge of checking
overlap in manual inserts/updates (or any java process) in c_period table
C_YEARPERIODS: db function associated to the create periods process inside the
Fiscal Calendar | Year tab. It also verifies the periods don't overlap other
periods.
The fix consists in checking that there is no date overlap per calendar. Before
this fix the calendar wasn't taken into account, so it was not possible to
define several calendars for the same organization with the same periods.
src-db/database/model/functions/C_YEARPERIODS.xml
src/org/openbravo/event/PeriodEventHandler.java
Víctor Martínez Romanos <[email protected]> null
Related to issue 29808: Backout wrong changeset
The changeset pushed was not the good one, and failed in Oracle
src-db/database/model/functions/C_YEARPERIODS.xml
src/org/openbravo/event/PeriodEventHandler.java
Unai Martirena <[email protected]> null
Related to bug 29884: Code Review
Add coalesce in case there is no batch associated to set GL Journal Org, in
order to avoid issues in the if condition done right after the query if null
values are compared
src-db/database/model/functions/GL_JOURNAL_POST.xml
Alvaro Ferraz <[email protected]> null
Fixes issue 29884: Error while completing a Simple G/L Journal in Oracle
A query in gl_journal_post has been changed to avoid errors in Oracle when
retrieving a null id
src-db/database/model/functions/GL_JOURNAL_POST.xml
Alvaro Ferraz <[email protected]> null
Fixes issue 29889 & Fixes issue 29887: Error in Price Correction Background
IsCostCalculated will not be considered to set CheckPriceDifference flag, when
completing an invoice.
Instead, when running Price Correction Background, transactions will be
filtered by IsCostCalculated to avoid calculate price differences in
transactions where cost has not been calculated.
src-db/database/model/functions/C_INVOICE_POST.xml
src/org/openbravo/costing/PriceDifferenceProcess.java
Eduardo Argal Guibert <[email protected]> null
Fixes issue 29899: False positives in GLJournalAccountingCheck validation
Missing ad_table_id constraint ends up in wrong validation when there are old
records using numeric values for ids.
src-util/buildvalidation/src/org/openbravo/buildvalidation/GLJournalAccountingCheck_data.xsql
Unai Martirena <[email protected]> null
Related to bu 29891: Adjust costing tests to the new behavior
src-test/src/org/openbravo/test/costing/TestCosting.java
Unai Martirena <[email protected]> null
Fixes bug 29891: Total Movement qty fixed in costing tab with backdated trx
While working with cost adjustments, on certain cases the existing Costing
records changes. This can happen because the cost has been recalculated due to
backdated transactions, price adjustments, manual cost corrections, etc. In all
this cases the 'Total Movement Quantity' field was not being correctly updated.
This field has to store the current stock of the product on that moment. So,
each time the costing record is updated it is being checked if this value
changes, and if it has changed the current stock is set.
src/org/openbravo/costing/AverageCostAdjustment.java
Augusto Mauch <[email protected]> null
Fixes bug 29838: Prevents unlimited datasource requests when filtering the
grid
The problem was that the logic to check that if a datasource request was
triggered by scrolling up in a grid that did not have its initial rows loaded
(see [1]) did not work well when the user filtered the grid after having
scrolled down the grid till loading its second page. This caused the totalRows
property of the grid to be miscalculated, and this triggered the undefinite
amount of datasource requests.
The logic to check if the request was triggered by scrolling up has been
changed. Now, instead of checking low-level smartclient properties like
lastScrollTop, we check if there are rows loaded in the positions just after
the page that was just received. Only in that case we want to prevent resetting
the totalRows property of the ResultSet with the value returned by the
datasource.
[1]
https://code.openbravo.com/erp/devel/pi/rev/c51dce7e9fd3c47915464ab4f565a9d1cee60e3b
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/grid/ob-view-grid.js
Víctor Martínez Romanos <[email protected]> null
Fixed bug 29827: Open/Close Period Control shows calendars associated to
organizations
The Open/Close Period Control window was showing all the periods available at
the C_Period table.
The target of this window is to open/close periods in fiscal calendars, so it
should only show periods belonging to a fiscal calendar linked to an
organization set as ready.
The fix has 2 parts:
1. Added a hql where clause to include only periods belonging to a fiscal
calendar linked to an organization set as ready.
2. The hql filter clause was wrong because it was filtering by the
c_period.ad_org_id. Instead it should be filtering by the organization linked
to the calendar's periods
src-db/database/sourcedata/AD_TAB.xml
Víctor Martínez Romanos <[email protected]> null
Fixed bug 29808: Impossible to create several calendars for the same
organization
Two pieces of code were affected by this bug:
PeriodEventHandler.java: EntityPersistenceEventObserver in charge of checking
overlap in manual inserts/updates (or any java process) in c_period table
C_YEARPERIODS: db function associated to the create periods process inside the
Fiscal Calendar | Year tab. It also verifies the periods don't overlap other
periods.
The fix consists in checking that there is no date overlap per calendar. Before
this fix the calendar wasn't taken into account, so it was not possible to
define several calendars for the same organization with the same periods.
src-db/database/model/functions/C_YEARPERIODS.xml
src/org/openbravo/event/PeriodEventHandler.java
Unai Martirena <[email protected]> null
Fixes bug 29836: Avoid creating unnecessary backdated adjustments.
The problem was happening when costing precision was different from standard
precision. When calculating the expected cost of a transaction to know if an
adjustment is necessary to be created, it has to be rounded to standard
precision because the amounts always have to be created in standard precision.
In this case, while comparing expected cost with actual cost from database, as
in database values are rounded to standard precision, and expected cost was
being rounded to cost precission, an adjustment was being created with the
difference, that corresponds just to the precision lost, and finally an
adjustment of Zero amount was being created.
src/org/openbravo/costing/AverageCostAdjustment.java
Sandra Huguet <[email protected]> null
Fixed bug 29780 The done button appears disabled when it should not
null parameter when it should be the view in recalcDisplayLogicOrReadOnlyLogic
call in updateDifference function
modules/org.openbravo.advpaymentmngt/web/org.openbravo.advpaymentmngt/js/ob-aprm-addPayment.js
RM packaging bot <[email protected]> null
Merge temporary head for 3.0PR15Q1.4
RM packaging bot <[email protected]> null
Added signature for changeset ac3537eef819
.hgsigs
RM packaging bot <[email protected]> null
Added tag 3.0PR15Q1.4 for changeset d5ec99ff8e8e
.hgtags
RM packaging bot <[email protected]> null
Update AD_MODULE version to 3.0PR15Q1.4
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
Víctor Martínez Romanos <[email protected]> null
Fixed bug 29809: Impossible to create several calendars for the same
organization
Two pieces of code were affected by this bug:
PeriodEventHandler.java: EntityPersistenceEventObserver in charge of checking
overlap in manual inserts/updates (or any java process) in c_period table
C_YEARPERIODS: db function associated to the create periods process inside the
Fiscal Calendar | Year tab. It also verifies the periods don't overlap other
periods.
The fix consists in checking that there is no date overlap per calendar. Before
this fix the calendar wasn't taken into account, so it was not possible to
define several calendars for the same organization with the same periods.
src-db/database/model/functions/C_YEARPERIODS.xml
src/org/openbravo/event/PeriodEventHandler.java
Víctor Martínez Romanos <[email protected]> null
Related to issue 29809: Backout wrong changeset
The changeset pushed was not the good one, and failed in Oracle
src-db/database/model/functions/C_YEARPERIODS.xml
src/org/openbravo/event/PeriodEventHandler.java
Unai Martirena <[email protected]> null
Related to bug 29885: Code Review
Add coalesce in case there is no batch associated to set GL Journal Org, in
order to avoid issues in the if condition done right after the query if null
values are compared
src-db/database/model/functions/GL_JOURNAL_POST.xml
Alvaro Ferraz <[email protected]> null
Fixes issue 29885: Error while completing a Simple G/L Journal in Oracle
A query in gl_journal_post has been changed to avoid errors in Oracle when
retrieving a null id
src-db/database/model/functions/GL_JOURNAL_POST.xml
Alvaro Ferraz <[email protected]> null
Fixes issue 29890 & Fixes issue 29888: Error in Price Correction Background
IsCostCalculated will not be considered to set CheckPriceDifference flag, when
completing an invoice.
Instead, when running Price Correction Background, transactions will be
filtered by IsCostCalculated to avoid calculate price differences in
transactions where cost has not been calculated.
src-db/database/model/functions/C_INVOICE_POST.xml
src/org/openbravo/costing/PriceDifferenceProcess.java
Eduardo Argal Guibert <[email protected]> null
Fixes issue 29900: False positives in GLJournalAccountingCheck validation
Missing ad_table_id constraint ends up in wrong validation when there are old
records using numeric values for ids.
src-util/buildvalidation/src/org/openbravo/buildvalidation/GLJournalAccountingCheck_data.xsql
Jorge Garcia <[email protected]> null
Fixed issue 29776: Header of warehouse picking module do not refresh
Header of warehouse picking module do not refresh in some circunstances.
Issue of platform.
The problem was that the toolbar didn't update when the Manage Incidences
process finished.
The solution is to update the toolbar when the ActionHandler return the
responded JSON.
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/process/ob-parameter-window-view.js
Unai Martirena <[email protected]> null
Fixes bug 29892: Total Movement qty fixed in costing tab with backdated trx
While working with cost adjustments, on certain cases the existing Costing
records changes. This can happen because the cost has been recalculated due to
backdated transactions, price adjustments, manual cost corrections, etc. In all
this cases the 'Total Movement Quantity' field was not being correctly updated.
This field has to store the current stock of the product on that moment. So,
each time the costing record is updated it is being checked if this value
changes, and if it has changed the current stock is set.
src/org/openbravo/costing/AverageCostAdjustment.java
Alvaro Ferraz <[email protected]> null
Fixes issue 29873: Wrong accounts when posting multi-general ledger G/L
Journal
When getting accounts from GL Item (while posting a Simple G/L Journal setted
as multi-general ledger), they were setted wrongly to accounting lines
src/org/openbravo/erpCommon/ad_forms/DocLine_GLJournal.java
Alvaro Ferraz <[email protected]> null
Fixes issue 29876: Avoid error when posting a multi-general ledger G/L
Journal
General Ledger will be taken from G/L Item instead from Simple G/L Journal when
it is marked as multi-general ledger, because in this case General Ledger from
Simple G/L Journal will be empty
src/org/openbravo/erpCommon/ad_forms/DocGLJournal_data.xsql
Augusto Mauch <[email protected]> null
Fixes bug 29839: Prevents unlimited datasource requests when filtering the
grid
The problem was that the logic to check that if a datasource request was
triggered by scrolling up in a grid that did not have its initial rows loaded
(see [1]) did not work well when the user filtered the grid after having
scrolled down the grid till loading its second page. This caused the totalRows
property of the grid to be miscalculated, and this triggered the undefinite
amount of datasource requests.
The logic to check if the request was triggered by scrolling up has been
changed. Now, instead of checking low-level smartclient properties like
lastScrollTop, we check if there are rows loaded in the positions just after
the page that was just received. Only in that case we want to prevent resetting
the totalRows property of the ResultSet with the value returned by the
datasource.
[1]
https://code.openbravo.com/erp/devel/pi/rev/c51dce7e9fd3c47915464ab4f565a9d1cee60e3b
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/grid/ob-view-grid.js
Víctor Martínez Romanos <[email protected]> null
Fixed bug 29823: Open/Close Period Control shows calendars associated to
organizations
The Open/Close Period Control window was showing all the periods available at
the C_Period table.
The target of this window is to open/close periods in fiscal calendars, so it
should only show periods belonging to a fiscal calendar linked to an
organization set as ready.
The fix has 2 parts:
1. Added a hql where clause to include only periods belonging to a fiscal
calendar linked to an organization set as ready.
2. The hql filter clause was wrong because it was filtering by the
c_period.ad_org_id. Instead it should be filtering by the organization linked
to the calendar's periods
src-db/database/sourcedata/AD_TAB.xml
Víctor Martínez Romanos <[email protected]> null
Fixed bug 29809: Impossible to create several calendars for the same
organization
Two pieces of code were affected by this bug:
PeriodEventHandler.java: EntityPersistenceEventObserver in charge of checking
overlap in manual inserts/updates (or any java process) in c_period table
C_YEARPERIODS: db function associated to the create periods process inside the
Fiscal Calendar | Year tab. It also verifies the periods don't overlap other
periods.
The fix consists in checking that there is no date overlap per calendar. Before
this fix the calendar wasn't taken into account, so it was not possible to
define several calendars for the same organization with the same periods.
src-db/database/model/functions/C_YEARPERIODS.xml
src/org/openbravo/event/PeriodEventHandler.java
Unai Martirena <[email protected]> null
Fixes bug 29837: Avoid creating unnecessary backdated adjustments.
The problem was happening when costing precision was different from standard
precision. When calculating the expected cost of a transaction to know if an
adjustment is necessary to be created, it has to be rounded to standard
precision because the amounts always have to be created in standard precision.
In this case, while comparing expected cost with actual cost from database, as
in database values are rounded to standard precision, and expected cost was
being rounded to cost precission, an adjustment was being created with the
difference, that corresponds just to the precision lost, and finally an
adjustment of Zero amount was being created.
src/org/openbravo/costing/AverageCostAdjustment.java
Sandra Huguet <[email protected]> null
related to issue 28971, related to issue 29781
handleButtonsStatus function does not exist in q1
modules/org.openbravo.advpaymentmngt/web/org.openbravo.advpaymentmngt/js/ob-aprm-addPayment.js
Sandra Huguet <[email protected]> null
related to issue 29781 apply js beautifier
modules/org.openbravo.advpaymentmngt/web/org.openbravo.advpaymentmngt/js/ob-aprm-addPayment.js
Sandra Huguet <[email protected]> null
Fixed bug 29781 The done button appears disabled when it should not
null parameter when it should be the view in recalcDisplayLogicOrReadOnlyLogic
call in updateDifference function
modules/org.openbravo.advpaymentmngt/web/org.openbravo.advpaymentmngt/js/ob-aprm-addPayment.js
Inigo Sanchez <[email protected]> null
Fixed bug 29760:Problems with inherited permissions in process definition
The problem was that when a process containing parameters defined as "window" is
launched , this manual role has not access to windows contained in that process
definition.
The cause of this issue is that before 14Q3, no security check was done on P&E
grids, so data always was retrieved.From 15Q1, security is checked requiring
explicit access to P&E grid.
The issue is fixed by inheriting access from the process, this is if the process
is accessible the grid within the P&E doesn't require to have explicit access
but inherits from the process itself.
modules/org.openbravo.client.application/src/org/openbravo/client/application/process/BaseProcessActionHandler.java
modules/org.openbravo.service.datasource/src/org/openbravo/service/datasource/DataSourceServlet.java
Unai Martirena <[email protected]> null
Fixes bug 29761: getCallableResult broken when using null parameters.
Removed TEST value for default
src-core/src/org/openbravo/database/RDBMSIndependent.java
Alvaro Ferraz <[email protected]> null
Fixes issue 29736: Wrong accounting in Cost Adjusment
Wrong accounting of the cost adjusment lines in case of Goods Movement From.
In this case, accounting should consider negative amounts, in order to have a
net effect of the goods movement adjustment accounting as 0.
src/org/openbravo/erpCommon/ad_forms/DocCostAdjustment.java
Eduardo Argal Guibert <[email protected]> null
Fixes issue 29727: Pressing Cancel in Match Statement or in Process
Reconciliation does not trigger a refresh.
Cancel button has been removed as it was considered confusing. Now there are
two buttons, one for closing the window called 'OK', as it was before, and
another one called 'Reconcile'.
Both triggers refresh. Messages have been added to improve user understanding
on how the window works. New message to inform the user any change will be
persisted. This message can be disabled once clear and will not popup again.
Message to run algorithm as well improved.
modules/org.openbravo.advpaymentmngt/src/org/openbravo/advpaymentmngt/actionHandler/MatchStatementOnLoadGetPreferenceActionHandler.java
modules/org.openbravo.advpaymentmngt/src/org/openbravo/advpaymentmngt/actionHandler/MatchStatementOnLoadPreferenceActionHandler.java
modules/org.openbravo.advpaymentmngt/src-db/database/sourcedata/AD_ELEMENT.xml
modules/org.openbravo.advpaymentmngt/src-db/database/sourcedata/AD_MESSAGE.xml
modules/org.openbravo.advpaymentmngt/src-db/database/sourcedata/AD_REFERENCE.xml
modules/org.openbravo.advpaymentmngt/src-db/database/sourcedata/AD_REF_LIST.xml
modules/org.openbravo.advpaymentmngt/src-db/database/sourcedata/OBUIAPP_PARAMETER.xml
modules/org.openbravo.advpaymentmngt/src/org/openbravo/advpaymentmngt/actionHandler/MatchStatementActionHandler.java
modules/org.openbravo.advpaymentmngt/web/org.openbravo.advpaymentmngt/js/ob-aprm-matchStatement.js
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/process/ob-parameter-window-view.js
Alvaro Ferraz <[email protected]> null
Fixes issue 29722: Payment navigation from Transaction tab is working wrong
Issotrx auxiliary input query in Transaction tab has been changed to get into
account related payment isreceipt field, when navigating from it to Payment
In/Out window
Also, SE_Payment_Transaction and SE_Trxtype_Transaction callouts have been
changed to overwrite issotrx session value when updating payment or
transactiontype fields
src-db/database/sourcedata/AD_AUXILIARINPUT.xml
src/org/openbravo/erpCommon/ad_callouts/SE_Payment_Transaction.java
src/org/openbravo/erpCommon/ad_callouts/SE_Trxtype_Transaction.java
David Baz Fayos <[email protected]> null
Fixed issue 29692: DateTime now works ok with 12:XX:XX times
The root of the problem was that there was a 'typo' and the
'minus' sign was missing in the 'if' statement in charge
of evaluate if it was in 24h mode or not. This was used later
to substract 12h to the entered date if this was in the
12:XX:XX form, change that obviously doesn't apply in the
24h mode
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/utilities/ob-utilities-date.js
Jorge Garcia <[email protected]> null
Fixed issue 29705: Description field is set with "null" in the FA
Transaction
Description field is filled in with "null" in the FA Transaction when matched
to GL Item.
The problem was in the Match Statement process, more specifically, in the
Add new transaction button. The AddTransanctionActionHandler didn't
take in consideration that the received description could be null.
The fix for this issue is to check if the received description is null
or blank.
Now, the description field fill in the correct description.
modules/org.openbravo.advpaymentmngt/src/org/openbravo/advpaymentmngt/actionHandler/AddTransactionActionHandler.java
Unai Martirena <[email protected]> null
Fixes bug 29678: Fix NPE in Costing Background with Standard Costing Rule
In Cost Adjustment project new method has been added to calculate an opening
inventory cost. This method uses 'CostingUtils.getStandardCostDefinition'
method, that tries to get an standard cost for that opening inventory. If it
does not found any standard or legacy cost, it returns null. So, in this moment
a NPE error was happening. To fix this problem, at this point a controlled
error is raised to notify the user that no cost has been found.
src/org/openbravo/costing/StandardAlgorithm.java
Víctor Martínez Romanos <[email protected]> null
Related to issue 29645: changed column in selector field
to get the right name, description and help for the selector's column
modules/org.openbravo.advpaymentmngt/src-db/database/sourcedata/OBUISEL_SELECTOR_FIELD.xml
Alvaro Ferraz <[email protected]> null
Fixes issue 29645: BP selector in AddTransaction shows all bp
"Business Partner selector" selector of "Business Partner" paramenter in
"AddTransaction" process definition, has been changed into "Business Partner
selector without default expressions" selector; in order to show all business
partners in the dropdown of the selector.
modules/org.openbravo.advpaymentmngt/src-db/database/sourcedata/AD_REFERENCE.xml
modules/org.openbravo.advpaymentmngt/src-db/database/sourcedata/OBUIAPP_PARAMETER.xml
modules/org.openbravo.advpaymentmngt/src-db/database/sourcedata/OBUISEL_SELECTOR.xml
modules/org.openbravo.advpaymentmngt/src-db/database/sourcedata/OBUISEL_SELECTOR_FIELD.xml
Alvaro Ferraz <[email protected]> null
Fixes issue 29660: GLItem lost in Add new Transaction window
Neither payment nor glitem will be deleted when changing to Bank fee in Add new
Transaction window. Instead, when clicking on Done and creating the
transaction, AddTransactionActionHandler will check if the transaction is of
type Bank fee and in this case it will set as null both fields.
modules/org.openbravo.advpaymentmngt/src/org/openbravo/advpaymentmngt/actionHandler/AddTransactionActionHandler.java
modules/org.openbravo.advpaymentmngt/web/org.openbravo.advpaymentmngt/js/ob-aprm-addTransaction.js
Víctor Martínez Romanos <[email protected]> null
Fixed bug 29655: Payment selector now filters by child organizations
The payment selector was incorrectly filtering by child organizations because
the order of the parameters in the call to the AD_ISORGINCLUDED function was
wrong.
It now gets all the payments belonging to the organization and any child
organization of the tab's organization.
src-db/database/sourcedata/OBUISEL_SELECTOR.xml
Alvaro Ferraz <[email protected]> null
Fixes issue 29634: Foreign currency not setted in transaction
When creating a transaction manually from a payment, foreign currency, foreign
conversion rate and foreign amount fields were not setted to transaction. Now,
they will be setted as in TransactionDao.java, when the transaction is
automatically created from the payment.
modules/org.openbravo.advpaymentmngt/src/org/openbravo/advpaymentmngt/process/FIN_TransactionProcess.java
Unai Martirena <[email protected]> null
Fixes bug 29620: Correctly used credit when paying an invoice and refunding
There were two issues while managing this scenario:
[1] In 'addCredit' method inside AddPaymentActionHandler.java class, a loop of
Credit to Use grid is done, creating Payment Credit Used records assigned to
the new created payment of the invoice. This method was not taking into account
that could be credit amount that exceeds the invoice amount (amount to be
refunded) and it was assigning all the credit amount as used to the payment of
the invoice. So the refund payment that is created right after was been left
without any used credit payment.
[2] After fixing the previous method, the second issue appears. The
'updateUsedCredit' method inside FIN_PaymentProcess.java class retrieves all
the payments of the business partner that has generated credit, and it assigns
as used to the refund payment. The problem with this function is that before
the Add Payment refactor it was not possible to select which credit payments we
wanted to consume, it was only a total credit amount to be consumed and the
system behind was being consuming any of them. But after the refactor it is
possible to select the ones that want to be consumed.
In order to fix this last issue the selected credit line ids are added as a
parameter to 'updateUsedCredit' method.
modules/org.openbravo.advpaymentmngt/src/org/openbravo/advpaymentmngt/actionHandler/AddPaymentActionHandler.java
modules/org.openbravo.advpaymentmngt/src/org/openbravo/advpaymentmngt/process/FIN_AddPayment.java
modules/org.openbravo.advpaymentmngt/src/org/openbravo/advpaymentmngt/process/FIN_PaymentProcess.java
Inigo Sanchez <[email protected]> null
Fixed bug 29629: setup application is not taking into account the context
name
The setup application is not taking into account the context name that users
are configuring. The values of "deploy-name" and "context-root" properties
of org.eclipse.wst.common.component are not updating.
Now it has been solved and if user set "context-name" in setup application.
this value is updating in org.eclipse.wst.common.component. For example if
a user set the context name as "test" the URL to go to Openbravo is
"http://localhost:8080/test"; instead of default one
"http://localhost:8080/openbravo";.
src/org/openbravo/configuration/ConfigurationApp.java
Asier Lostalé <[email protected]> null
related to bug 29902: added test case
src-test/src/org/openbravo/test/scheduling/ProcessSchedulingTest.java
src-test/src/org/openbravo/test/AllAntTaskTests.java
Asier Lostalé <[email protected]> null
fixed bug 29902: ProcessBundle.setCloseConnection(false) closes connection
When a process is invoked through ProcessRunner and its bundle is set as
setCloseConnection(false) there were 2 problems:
- connection was close after execution so it could not be reused by another
process invoking it
- ProcessRunner tried to update the process run status on a closed
connection
causing an error
The problem is caused by the fix for issue #27878 which correctly closes the
connection in DalConnectionProvider when invoking releaseCommitConnection. But
when setCloseConnection it relied in that bug not closing the connection to
leave it open.
The solution consists in doing directly the commit or rollback in
DalBaseProcess
without closing the connection.
src/org/openbravo/service/db/DalBaseProcess.java
Last 20 lines of the console output:
[...truncated 7355 lines...]
DEBUG: Tomcat stop called with parameters: ENABLED=ENABLE
* Stopping Tomcat servlet engine for Openbravo tomcat
...done.
executing script 'Check log'
[int-initial-pgsql] $ /bin/bash /tmp/build_step_template2036718558167492808.sh
ENABLE
DEBUG: Check log called with parameters: ENABLED=
Errors in openbravo.log:
b3e0edee 2015-05-21 16:11:55,757 [DefaultQuartzScheduler_Worker-2] ERROR
org.openbravo.erpCommon.ad_forms.AcctServer - Exception in AcctServer.run
Recording test results
Archiving artifacts
Checking \] ERROR|\] WARN
/srv/ci/workspace/int-initial-pgsql/SANDBOX/openbravo.log:
b3e0edee 2015-05-21 16:11:55,757 [DefaultQuartzScheduler_Worker-2] ERROR
org.openbravo.erpCommon.ad_forms.AcctServer - Exception in AcctServer.run
Build step 'Jenkins Text Finder' changed build result to UNSTABLE
Email was triggered for: Unstable
Sending email for trigger: Unstable
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Openbravo-builds mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openbravo-builds
