Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0013732
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] 01. General setupminoralways2010-06-22 17:112010-07-27 15:41
ReporteregoitzView Statuspublic 
Assigned Tosivaraman 
PriorityhighResolutionfixedFixed in Version
StatusclosedFix in branchpiFixed in SCM revision5013a579164c
ProjectionnoneETAnoneTarget Version2.50MP21
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product Version2.50MP18SCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0013732: The field where clause on the alert definition window does not work well if you want to refere to ad_user_id field

DescriptionThe field where clause on the alert definition window does not work well if you want to refere to ad_user_id field.
This happen because the ad_user_id column appear on the tables
ad_alert and ad_alertrecipient

you can not define the where clause as
ad_user_id=@#ad_user_id@

because when accesing to the alert form you get an error with
column ambiguosly defined.

If you used the alias of the column used you can access to the form,
but you get an error when modifying the counter of the alerts because
the alias is not valid for that.

Steps To Reproduce-Create an alert as following:

select req.m_requisition_id as referencekey_id,
       req.documentno as record_id,
       0 as ad_role_id,
       req.ad_user_id as ad_user_id,
       'La solicitud '||req.documentno||' no tiene descripcion' as description,
       'Y' as isActive,
        req.ad_org_id,
        req.ad_client_id,
        now() as created,
        0 as createdBy,
        now() as updated,
        0 as updatedby
  from m_requisition req
  where req.description is null;

tab= Header - Requisition
 whereclause, = ad_user_id=@#ad_user_id@

-Go to requisition window and create a new requisition without description.
-After receive the alert you won't be able to access to the alert form


If you change the whereclause to
a.ad_user_id=@#ad_user_id@
you can go to the form but the counter is not updated.

If you chage to
ad_alert.ad_user_id=@#ad_user_id@
you can not go to the form but the counter is updated.


Proposed SolutionRemove the alias of tables from the selects on the
AlertManagement_data.xsql
file
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]

-  Notes
(0029458)
hgbot (developer)
2010-07-22 06:33

 Repository: erp/devel/pi
Changeset: 5013a579164c66dd1a2958daa8c823e10584db84
Author: Sivaraman Rajagopal <sivaraman.rajagopal <at> openbravo.com>
Date: Thu Jul 22 10:02:25 2010 +0530
URL: http://code.openbravo.com/erp/devel/pi/rev/5013a579164c66dd1a2958daa8c823e10584db84 [^]

Fixes issue 13732: The field where clause on the alert definition window does not work well if you want to refere to ad_user_id field

Alias names of the tables have been removed from select queries in order to avoid ambiguity in defining where clause

---
M src/org/openbravo/erpCommon/ad_forms/AlertManagement_data.xsql
---
(0029460)
sivaraman (reporter)
2010-07-22 06:34

 Steps to test:

1. Create new Alert as follows
Name : New Alert Message
Active : Y
Sql :
select req.m_requisition_id as referencekey_id,
       req.documentno as record_id,
       0 as ad_role_id,
       req.ad_user_id as ad_user_id,
       'La solicitud '||req.documentno||' no tiene descripcion' as description,
       'Y' as isActive,
        req.ad_org_id,
        req.ad_client_id,
        now() as created,
        0 as createdBy,
        now() as updated,
        0 as updatedby
  from m_requisition req
  where req.description is null
Filter Clause : ad_alert.ad_user_id=@#ad_user_id@
Tab : Header - Requisition
2. Create new Requisition without description
3. Verify if alert count and form are displayed as expected.
(0029521)
sureshbabu (reporter)
2010-07-23 11:50

 Verified tested as per the steps mentioned by the developer
(0029598)
hudsonbot (developer)
2010-07-27 15:41

 A changeset related to this issue has been promoted to main after passing a series of tests and an OBX has been generated:

Changeset: http://code.openbravo.com/erp/devel/main/rev/5013a579164c [^]
Merge Changeset: http://code.openbravo.com/erp/devel/main/rev/634cc0909ed2 [^]
Tests: http://builds.openbravo.com/view/int/ [^]
OBX: http://builds.openbravo.com/erp/core/obx/OpenbravoERP-2.50CI.17922.obx [^]

- Issue History
Date Modified Username Field Change
2010-06-22 17:11 egoitz New Issue
2010-06-22 17:11 egoitz Assigned To => adrianromero
2010-06-22 17:21 egoitz Steps to Reproduce Updated View Revisions
2010-06-23 13:16 adrianromero Status new => scheduled
2010-06-23 13:16 adrianromero fix_in_branch => pi
2010-07-21 08:48 sivaraman Assigned To adrianromero => sivaraman
2010-07-22 06:33 hgbot Checkin
2010-07-22 06:33 hgbot Note Added: 0029458
2010-07-22 06:33 hgbot Status scheduled => resolved
2010-07-22 06:33 hgbot Resolution open => fixed
2010-07-22 06:33 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/5013a579164c66dd1a2958daa8c823e10584db84 [^]
2010-07-22 06:34 sivaraman Note Added: 0029460
2010-07-23 11:50 sureshbabu Note Added: 0029521
2010-07-23 11:50 sureshbabu Status resolved => closed
2010-07-24 00:00 anonymous sf_bug_id 0 => 3033800
2010-07-27 15:41 hudsonbot Checkin
2010-07-27 15:41 hudsonbot Note Added: 0029598

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker