|View Issue Details|
|Type||Category||Severity||Reproducibility||Date Submitted||Last Update|
|defect||[Openbravo ERP] 09. Financial management||major||have not tried||2014-01-20 09:50||2014-05-27 17:19|
|Priority||normal||Resolution||fixed||Fixed in Version|
|Status||closed||Fix in branch||Fixed in SCM revision||7b4ae1da74cb|
|OS Version||Database version||Ant version|
|Product Version||SCM revision|
|Review Assigned To||dmiguelez|
|Regression introduced in release|
|Regression introduced by commit|
|Triggers an Emergency Pack||No|
0025511: Performance problems with 2 alertrule created by ModuleScript: Issue21640WrongMatchInvAccounting
|Description||This Modulescript creates 2 sql-based Alertrules whose execution is in many cases really slow (up to 20-30 seconds).|
Technically this modulescript is inserting 2 ad_alertrule with its sql and then immediately executes those sql's to insert the needed ad_alert entries directly.
But as the ad_alertrule do exist and contain the sql they will be executed forever over and over again during the normal background alert processing.
Based on the description of the issue the purpose of those alerts is to check for wrong data created by some old accounting bug and to advise the user if any is found.
This means that after the check has been ran it is not needed to be ran again over the same data.
Disabling the sql in the alertrule would achieve that, as then the check would only be ran once (first time the modulescript is ran).
However this would switch of the part of marking the alerts as done automatically after the user did do the re-posting of the affected documents.
That could be avoided by special casing this in the modulescript. Adding a check if there art any alerts creating by this alertrule and then re-checking only those documents forever again (until the ad_alerts are deleted or marked as solved).
|Steps To Reproduce||-|
|Proposed Solution||The ad_alertrule table has a 'type' column which is normally set to 'D' (data-driven, aka sql-based) having the usual semantics.|
However there is also a type 'E' (external) which does nothing as a rule but exists so that some custom code can do the ad_alert inserts.
Note: That this type 'E' in practice has never been used so needs to be tested first if it works fine.
Assuming it does:
- The ModuleScript should be changed to insert the ad_alertrule with type 'E'
- For that it needs to 'find' it rules based on name instead of sql as the alertrule will no longer contain the sql.
- Furthermore the existing ad_alertrule created by previous execution of this modulescript should be changed from type=D to type=E and have their sql removed.
Note: It is important to have the sql-column empty as the current AlertProcess.java code filters for that when processing alerts and is not using the type=D.
Note when the last part of the description should be implemented code for this needs to be added to the modulescript to:
- get alertrule by from name
- select ad_alert for this ad_alertrule_id having status not yet solved
- for those docuents only, recheck the consistency with the sql.
- After applying the fix, for module script execution either do ant smartbuild -Dlocal=no or ant update.database
- Check that alert rule for wrong matched invoice posting if exists are set with blank SQL and type ='E'.
- If alert rule for wrong matched invoice posting does not exists then new alert rules created are set with blank SQL and type ='E'.
Author: Atul Gaware <atul.gaware <at> openbravo.com>
Date: Fri Jan 24 14:30:20 2014 +0530
URL: http://code.openbravo.com/erp/devel/pi/rev/7b4ae1da74cb2c7a0e06c1fc28a8fba7d18edf4a [^]
Fixes Issue 25511:WrongMatchInvAccounting modulescript alertrule performance
|Code Review + Testing OK|
A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.
Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/d1a5bb862230 [^]
Maturity status: Test
|2014-01-20 09:50||shuehner||New Issue|
|2014-01-20 09:50||shuehner||Assigned To||=> dmiguelez|
|2014-01-20 09:50||shuehner||Modules||=> Core|
|2014-01-20 09:50||shuehner||Triggers an Emergency Pack||=> No|
|2014-01-20 09:53||shuehner||Tag Attached: Performance|
|2014-01-20 12:01||pramakrishnan||Target Version||=> 3.0MP32|
|2014-01-21 09:34||AtulOpenbravo||Assigned To||dmiguelez => AtulOpenbravo|
|2014-01-27 10:39||AtulOpenbravo||Status||new => scheduled|
|2014-01-27 10:39||AtulOpenbravo||fix_in_branch||=> pi|
|2014-01-27 10:46||AtulOpenbravo||Note Added: 0063705|
|2014-01-27 10:47||AtulOpenbravo||Review Assigned To||=> dmiguelez|
|2014-01-27 10:47||AtulOpenbravo||fix_in_branch||pi =>|
|2014-01-27 10:52||hgbot||Note Added: 0063706|
|2014-01-27 10:52||hgbot||Status||scheduled => resolved|
|2014-01-27 10:52||hgbot||Resolution||open => fixed|
|2014-01-27 10:52||hgbot||Fixed in SCM revision||=> http://code.openbravo.com/erp/devel/pi/rev/7b4ae1da74cb2c7a0e06c1fc28a8fba7d18edf4a [^]|
|2014-01-27 12:40||dmiguelez||Note Added: 0063717|
|2014-01-27 12:40||dmiguelez||Status||resolved => closed|
|2014-02-12 18:29||hudsonbot||Note Added: 0064116|
|2014-05-27 17:19||rafaroda||Note Added: 0067484|
|2014-05-27 17:38||shuehner||Note Deleted: 0067484|
|2014-06-03 16:30||maite||Relationship added||related to 0026772|
|Copyright © 2000 - 2009 MantisBT Group|