Thu, 20 Aug 2015 17:41:15 +0000CI: update AD_MODULE to version 27380
RM packaging bot <staff.rm@openbravo.com> [Thu, 20 Aug 2015 17:41:15 +0000] rev 27381
CI: update AD_MODULE to version 27380

Wed, 19 Aug 2015 20:39:40 +0200Related to issue 30600: Fix Locator selector in Goods Movement window
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Wed, 19 Aug 2015 20:39:40 +0200] rev 27380
Related to issue 30600: Fix Locator selector in Goods Movement window

Organization parameter will be correctly setted in Goods Movement window

Wed, 19 Aug 2015 15:23:17 +0200Fixes issue 30600: Backout commits from issue 30463
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Wed, 19 Aug 2015 15:23:17 +0200] rev 27379
Fixes issue 30600: Backout commits from issue 30463

Thu, 20 Aug 2015 11:52:13 +0200Issue 30602: Undeclare merge for the moment until clear how it can be done.
Stefan Hühner <stefan.huehner@openbravo.com> [Thu, 20 Aug 2015 11:52:13 +0200] rev 27378
Issue 30602: Undeclare merge for the moment until clear how it can be done.

'Allow changes in minor version' in CR does not cover merges at the moment.
Undeclare the merge for now until a proper solution can be found.

Wed, 19 Aug 2015 23:48:07 +0530Fixes Issue 30504:"Gross List Price" information is not copied to invoice
Atul Gaware <atul.gaware@openbravo.com> [Wed, 19 Aug 2015 23:48:07 +0530] rev 27377
Fixes Issue 30504:"Gross List Price" information is not copied to invoice
when using Generate Invoice from Receipt process

In m_inout_createinvoice function while copying order line information,
grosspricelist and grosspricestd are fetched and set properly in purchase
invoice line.

Wed, 19 Aug 2015 12:18:15 +0200Fixed 30602. Moe module merge from core to org.openbravo.v3
Stefan Hühner <stefan.huehner@openbravo.com> [Wed, 19 Aug 2015 12:18:15 +0200] rev 27376
Fixed 30602. Moe module merge from core to org.openbravo.v3

That is required as declaring module merge normally requires to raise major
version and only the org.openbravo.v3 has an exception allowed for this rule.

Wed, 19 Aug 2015 09:12:26 +0200Related with issue 30525: Fixes problem with merge
Augusto Mauch <augusto.mauch@openbravo.com> [Wed, 19 Aug 2015 09:12:26 +0200] rev 27375
Related with issue 30525: Fixes problem with merge

Wed, 19 Aug 2015 09:05:39 +0200Related with issue 30179: Fixes problem with merge
Augusto Mauch <augusto.mauch@openbravo.com> [Wed, 19 Aug 2015 09:05:39 +0200] rev 27374
Related with issue 30179: Fixes problem with merge

Wed, 19 Aug 2015 08:47:15 +0200Fixes issue 30525: Supports the use of Operator Classes in index columns
Augusto Mauch <augusto.mauch@openbravo.com> [Wed, 19 Aug 2015 08:47:15 +0200] rev 27373
Fixes issue 30525: Supports the use of Operator Classes in index columns

The fix is very straightforward in PostgreSQL: if the column of an index defines an operator class, that operator class is included in the XML, and viceversa. This is very easy to do be
cause the info about the operator class used in the index column is stored in the indclass column of the pg_index table.

It gets more complicated for Oracle. Oracle does not have the concept of operator class, so when an index that defines one is imported, there is no standard place where to store it. And
it really needs to be stored, because otherwise when that index is exported from Oracle it would lose the operator class. To solve this, the operator classes used by index columns are
stored as comments in the table that owns the indexes with the following format:
"indexName1.indexColumn1.operatorClass=operatorClass1$indexName2.indexColumn2.operatorClass=operatorClass2$..."

These comments need to be updated each time an index that defines an operator class is added or removed, both when it is done at the same time of the table creation or after it.

The operator classes used in the index columns should not be taken into account when comparing indexes in Oracle. With this we achieve that indexes will not be recreated in oracle if the only change is tha
t an operator class has been added/removed from an index column.

Wed, 19 Aug 2015 08:36:11 +0200Fixes issue 30179: Adds support to function based indexes in dbsourcemanager
Augusto Mauch <augusto.mauch@openbravo.com> [Wed, 19 Aug 2015 08:36:11 +0200] rev 27372
Fixes issue 30179: Adds support to function based indexes in dbsourcemanager

Now it is possible to export and import indexes whose columns use functions, for instance:

CREATE INDEX c_bpartner_upper_name
ON c_bpartner
USING btree
(upper(name) COLLATE pg_catalog."default");

CREATE INDEX c_bpartner_upper_replace_name
ON c_bpartner
USING btree
(replace(upper(name),'A','B') COLLATE pg_catalog."default");

There are two restrictions:
1- An index cannot have more than one column that uses a function expression. So this is supported:

CREATE INDEX c_bpartner_upper_replace_name_id
ON c_bpartner
USING btree
(replace(upper(name),'A','B') COLLATE pg_catalog."default", id);

But this is not:

CREATE INDEX c_bpartner_upper_replace_name_id
ON c_bpartner
USING btree
(replace(upper(name),'A','B') COLLATE pg_catalog."default", upper(id));

2- A function expression should not contain empty strings. In Oracle an empty String is treated as NULL, so if one index is imported with a function containing an empty string parameter, when that index is exported the empty string will be replaced by NULL.