up-2.50topi-oracle - Build # 209 - Fixed:
Check console output at https://ci.openbravo.com/job/up-2.50topi-oracle/209/ to
view the results.
Committers since last success:
Changes for Build #208
Inigo Sanchez <[email protected]> null
Fixed issue 36610: 3* flush called to insert/save 1 record in generated
windows
Those flushes were added for pre/post actions, which in most of the cases are
unimplemented. For this
reason, removing those two flushes would improve the common case.
After removing those flushes, it is required to move those flushes to pre/post
actions implemented in
org.openbravo.module.resources module.
The problem has been resolved because the extra flushes are removed.
modules/org.openbravo.service.json/src/org/openbravo/service/json/DefaultJsonDataService.java
Carlos Aristu <[email protected]> null
fixes bug 37016: Disable print/e-mail buttons on record creation in grid
view
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/toolbar/ob-toolbar.js
Carlos Aristu <[email protected]> null
fixes issue 36916: PG10 - update.database fails if there are DB sequences
src-db/database/lib/dbsourcemanager.jar
Inigo Sanchez <[email protected]> null
Fixed bug 36928: Emails sent by alerts contains information about other
clients
The problem was that emails sent by alerts contains information about other
entities. For example, when sending
an alert by email within the 'White Valley Group Admin' client, it also sends
information about 'F&B Group Admin'
client. The generation of the body of the email was filtering by organization
but was not filtering by client too.
The problem has been resolved by take into account the client info properly.
Now the data used in the generation
of the email is filtering properly.
src/org/openbravo/erpCommon/ad_process/AlertProcess.java
Inigo Sanchez <[email protected]> null
Fixed bug 36886:install.source finishes with success even if an error is
raised
The problem is that install.source task could finished with success even if a
view cannot be created. If there is a
problem with the definition of a view (i.e. the view references a table that
does not exist), the install.source
task will finish with a success message, even though error logs will be written
in console output. If the
update.database task is executed instead of install.source, the task will end
with error.
Now the problem has been resolved by take into account the same errors/problems
on install.source task than on
update.database. The following methods now are managed in order to retrieve the
potential errors and stop the
task if and error is raised:
- platform.createTables(..)
- platform.createAllFKs(..)
- platform.enableAllTriggers(..)
Now on install.source taks the errors are handled properly.
src-db/database/lib/dbsourcemanager.jar
Carlos Aristu <[email protected]> null
fixes bug 36931: Check data access level of process definitions
The data access level of the process definition was not being checked. Now,
it is verified in the BaseProcessActionHandler before executing any action. In
particular the check will be performed by the defaults action handler of each
process definition.
In addition, some code has been added for the OBBaseParameterWindowView
class, in order to handle properly in the client the error message coming from
the server side when the access level of the process definition is not allowed
in the current context
modules/org.openbravo.client.application/src/org/openbravo/client/application/process/BaseProcessActionHandler.java
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/process/ob-base-parameter-window-view.js
src/org/openbravo/dal/security/EntityAccessChecker.java
Carlos Aristu <[email protected]> null
fixes bug 36970: Return focus to the record if failed to be edited in grid
view
When a record failed to be edited in grid view right after moving to the form
view of its parent record, the window ended in an inconsitent state:
- The focus was placed at the header
- The active view still was the child tab
This was not happening when editing the child record in form view, because
the focus was always returned to the form. To fix the problem now the same
behavior has been implemented in grid view: in the described scenario the focus
is returned to the edit form of the grid.
Besides, the "editRow" and "editSession" variables were unused in the
editFailed() function. Thus, both have been removed.
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/grid/ob-view-grid.js
Carlos Aristu <[email protected]> null
fixes bug 35136: Line seems to be saved with error after saving the header
When saving a record, the content of its child tabs is automatically
refreshed. In case we leave a child record in error status and then we edit and
save its parent record, the content of the child record is automatically
refreshed with the server data and the error state in the UI disappears,
nevertheless, the problem was that the edits was not being discarded properly
causing the record to show outdated information.
Now when the tab is refreshed if it contains records with errors, then the
edits are discarded allowing to show the real contents of the records.
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/main/ob-standard-view.js
Carlos Aristu <[email protected]> null
related to issue 36927: update copyright year
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/form/formitem/ob-formitem-minidaterange.js
Carlos Aristu <[email protected]> null
fixes bug 36927: Multiple DS requests having a date item as first focused
item
When directly opening a record in a tab which has a date item as the first
focused item, extra DS calls were fired which could prevent the record to be
opened properly (the form displayed in blank)
This has happening because a combination of different facts:
- When the grid is redrawn, Smarclient fires an update of the first focused
item. In the case of date items this causes that false item edition is fired
because it detects that the value of the date item filter changes from
undefined to empty string.
- If the previous scenario happens while opening a record directly, the grid
datasource detects that it needs to fetch data because at this point the number
of cached rows is different from the total rows (see [1]).
To avoid those extra DS requests we now ignore those false item editions
while a target record is being opened.
[1]
https://code.openbravo.com/erp/mods/org.openbravo.userinterface.smartclient.dev/file/66d2b640b66e/web/org.openbravo.userinterface.smartclient/isomorphic/client/application/ResultSet.js#l833
modules/org.openbravo.client.application/web/org.openbravo.client.application/js/form/formitem/ob-formitem-minidaterange.js
Asier Lostalé <[email protected]> null
fixed issue 36938, fixed issue 36996: dbsm for these issues
- removed unused platforms
- refactorized code to better reuse in tests
- test properly apply ad updates
src-db/database/lib/dbsourcemanager.jar
Mark <[email protected]> null
Fixes issue 36969: Purchase order created from Requisitions created with 0
price
Purchase order lines created from Requisitions are created with 0 price if price
list includes taxes and a discount is defined.
When M_REQUISITION_CREATEPO process is executed it creates the order and its
lines.
Then it call the C_ORDER_POST1, to process the created order and it calls the
M_PROMOTION_CALCULATE to recalculate prices and quantities if discounts, and in
this case it uses the grosspricestd of lines to recalculates the
gross_unit_price
and line_gross_amount if price list includes taxes:
if (v_taxIncluded = 'Y') then
update c_orderline set
gross_unit_price = grosspricestd,
line_gross_amount = round(grosspricestd * qtyordered, v_stdPrecision)
where c_orderline_id = Cur_Order.id;
The process was failling because order lines were created without a
GROSSPRICESTD
column defined, and it was taking 0 instead of the right price. Due that, when
the
values of the lines were recalculated to apply discounts it reset all values to
ZERO
and order ends with incorrect totals.
To avoid that, the GROSSPRICESTD is defined when the lines are created.
src-db/database/model/functions/M_REQUISITION_CREATEPO.xml
Changes for Build #209
Guillermo Alvarez de Eulate <[email protected]> null
Related to issue 36966: Update license text
src-db/database/model/functions/M_GETJSONDESCRIPTION.xml
Asier Lostalé <[email protected]> null
fixed bug 28479: unneeded queries to ad_langue
Backports HHH-11703 [1] Hibernate issue that adds objects initialized by a
unique contraint to 1st level cache. In this way, only one query per different
language is executed per request (which typically is just one) instead one per
record initialized.
Find code for backport here [2].
---
[1] https://hibernate.atlassian.net/browse/HHH-11703
[2] https://github.com/alostale/hibernate-orm
lib/runtime/hibernate3-patched.jar
Guillermo Alvarez de Eulate <[email protected]> null
Related to issue 36966: Add PL function to retrieve json details about
certain m_attsetinstance_id
src-db/database/model/functions/M_GETJSONDESCRIPTION.xml
modules/org.openbravo.client.kernel/src/org/openbravo/client/kernel/KernelApplicationInitializer.java
src-db/database/sourcedata/AD_MESSAGE.xml
David Miguelez <[email protected]> null
Related to Issue 36693. Code Review Changes:
* Improved error message when standard precission is a negative number
* Improved some Java Doc
* Removed some unnecessary Java Doc
* Reordering tags in definition of constants to compile with standards
* Rearranged Code to improve redability
* Added log.error when file has not been found
src-db/database/sourcedata/AD_MESSAGE.xml
src/org/openbravo/erpCommon/ad_callouts/SL_Currency_StdPrecision.java
Mark <[email protected]> null
Fixes issue 36693:Std precision can be higher than the currency's real
precision
In Currency window, Standard precision can be higher than the currency's real
precision (commonly 2). The Standard Precision is used to round all the amounts
(not prices) of the documents created in the backend.
Was created a new callout used to validate the currency standard precision. If
the new precision is higher than specified currency precision in ISO 4217
Currency
codes, then a warning is showed to user.
Also, if the new precision is negative then an error message is shown and it is
set as the default standard precision: 2.
src/org/openbravo/erpCommon/ad_callouts/ISO_4217.xml
src/org/openbravo/erpCommon/ad_callouts/SL_Currency_StdPrecision.java
src-db/database/sourcedata/AD_CALLOUT.xml
src-db/database/sourcedata/AD_COLUMN.xml
src-db/database/sourcedata/AD_MESSAGE.xml
src-db/database/sourcedata/AD_MODEL_OBJECT.xml
src-db/database/sourcedata/AD_MODEL_OBJECT_MAPPING.xml
Inigo Sanchez <[email protected]> null
Fixed issue 37051: Rich text area fields causes visibility problems in the
grid
The problem was that the rich text area fields generated visibility problems in
the grid under some circumstances.
(e.g. when a rich text area field has a carriage return or html tags such as
div, br,etc.). A common usecase could
be when a text is copied from a website.
This visibility problems occurred because in form view this type of fields are
visualized as a rich text editor and
html tags are supported but in grid view are visualized as a normal field in
the grid and this html tags are not
properly handled by SC.
In order to avoid this grid visibility problems, when showing a rich text area
field in grid view, now it is escaped
the html code. Visibility in form view is not changed. Now the problem has been
fixed by taking account this situation
in getGridFieldProperties method of the RichTextUIDefinition reference.
modules/org.openbravo.client.kernel/src/org/openbravo/client/kernel/reference/RichTextUIDefinition.java
David Miguelez <[email protected]> null
Related to Issue 36878. Code Review Fixes
* In ReportValuedStock.java, when looking for the last costing rule
filter by validated costing rules
* In queries, check that the warehouses are equal only when the warehouse
dimension is Y
* Use left join with the M_Costing subqueri instead of a join
src/org/openbravo/erpCommon/ad_reports/ReportValuationStock.java
src/org/openbravo/erpCommon/ad_reports/ReportValuationStock_data.xsql
David Miguelez <[email protected]> null
Related to Issue 36878. Code Review fixes:
* Removed query to retrieve last M_Costing in Consolidated with cost query
for the group of Transactions without Cost calculated. This must be null
* Take into account Warehouse Dimension in both queries that look for costs
- In not consolidated, if the Warehouse Dimension is checked, the Warehouse
of the Costing record must be the same one as the Transaction
- In the consolidated, the Organization of the Warehouse of the Costing
record
must belong to the Organization of the filter of the Report. In this case,
the average of the Costing records must be returned as the last costing
record
src/org/openbravo/erpCommon/ad_reports/ReportValuationStock.java
src/org/openbravo/erpCommon/ad_reports/ReportValuationStock_data.xsql
Mark <[email protected]> null
Fixes issue 36878: [Valued Stock Report]: Wrong Actual Cost and Valuation
if the costing rule is validated with warehouse dimension.
Incorrect computation was made because costs related to transactions were not
grouped by warehouse and more than one cost could be showed with the cost of the
current line related to it. To fix this issue were took into account that if the
costing rule has the warehouse dimension activated, costs will be related to
them
and calculated taking into account the transaction's warehouse. If the costing
rule
hasn't the Warehouse dimension activated, then cost doesn't has the warehouse
column
filled. Both cases are taken into account to a correct computation of costs.
Also was fixed when Consolidated warehouse option is choosed.
src/org/openbravo/erpCommon/ad_reports/ReportValuationStock_data.xsql
Inigo Sanchez <[email protected]> null
Fixed issue 37005: Error importing C_UOM translation
The problem was discovered when you was trying to import the es_ES translation
for Core. Running install.source
task (having org.openbravo.localization.spain.referencedata.translation.esES
module in the instance) some C_UOM
translations were not found. The problem was the order in wich translations
were applied. (Before the import of
standard reference data).
The ApplyModule task import the data first for any translation modules. Then
ApplyModule task import the reference
data modules. This order is wrong because some translations could be depend on
the reference data.
Now the problem has been resolved by take into account this situation. Now, the
import of the reference data are
done at first. Then the translations are applied.
src/org/openbravo/erpCommon/modules/ApplyModule.java
Last 20 lines of the console output:
[...truncated 4406 lines...]
Connected to:
Oracle Database 11g Release 11.2.0.1.0 - 64bit Production
SQL>
Call completed.
SQL> Disconnected from Oracle Database 11g Release 11.2.0.1.0 - 64bit Production
+ run_ora_command 'column object_name format a32
SELECT object_id, object_name, object_type FROM user_objects WHERE
status<>'\''VALID'\'' AND object_type IN('\''VIEW'\'', '\''PACKAGE'\'',
'\''PACKAGE BODY'\'', '\''FUNCTION'\'', '\''PROCEDURE'\'', '\''TRIGGER'\'',
'\''JAVA CLASS'\'') ORDER BY object_type, object_name;'
+ ssh [email protected]
Pseudo-terminal will not be allocated because stdin is not a terminal.
+ grep -q OBJECT_ID /tmp/int-dbcons-oracle_objects
+ true
+ exit 0
Checking console output
Email was triggered for: Fixed
Trigger Success was overridden by another trigger and will not send an email.
Sending email for trigger: Fixed
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openbravo-builds mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openbravo-builds
