for info: looks like known bug (corner case) accounting server running just when tomcat is shutdown end of the test -> makes currently running accounting serve fail.
Re-running job... On Thu, May 21, 2015 at 6:11 PM, <[email protected]> wrote: > 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
