|View Issue Details|
|Type||Category||Severity||Reproducibility||Date Submitted||Last Update|
|defect||[Openbravo ERP] 00. Application dictionary||minor||always||2011-03-22 07:29||2011-04-09 00:00|
|Priority||normal||Resolution||fixed||Fixed in Version|
|Status||closed||Fix in branch||pi||Fixed in SCM revision||1f6ef3054d8d|
|OS Version||Database version||9.0||Ant version|
|Product Version||pi||SCM revision|
|Review Assigned To|
|Regression introduced in release|
|Regression introduced by commit|
|Triggers an Emergency Pack||No|
0016407: New business partner selector incorrectly filters out valid business partners
|Description||If a business partner has a contact defined where that contact has a partner address set, then the business partner does not appear in the selector in any invoices, orders, etc.|
The 3.0 template has removed the partner address field from the contact tab within business partner, but it is still possible to have the partner address set via the user screen, legacy data or a template that reenables the field.
|Steps To Reproduce||1) Create a business partner|
2) Add a location for that partner
3) Add a contact for the partner
4) Go to the users window, remove the filter, select the contact you just added and select a value for the partner addres
5) Create a sales order
6) Try to select the business partner you just created.
|Proposed Solution||The problem is caused because the selector is filtering by "usercontact.partnerAddress is null". I am guessing this is trying to make the selector only pick up contact records and not user records.|
In that case a better filter would be "usercontact.username is null"
|Tags||No tags attached.|
|Attached Files||16407.patch [^] (820 bytes) 2011-04-03 13:19 [Show Content]|
After looking at this a bit more I think that the best solution is to remove the filter on usercontact.partnerAddress and not replace it with anything.
It is valid for a business partner contact to have a address specified and/or to be a user in the system (e.g. contractors)
After internal discussion and some testing we have agreed that your solution is correct. So I'll apply the patch provided.
I've reviewed the HQL, and I'm going to make a slightly different patch. The issue was on the left join and I've managed to fix it. With the constraint in the where clause it was converting the left join of "usercontact" into an inner join. I've changed it to use the "with" clause on the left join and is working now.
For each location we expect to have only contacts assigned to that location. And if no contact is assigned to it only contacts not assigned to any location will be available. With your patch the first assumption is solved, but when a location doesn't have any contact assigned all the contacts would be available, fixing the left join these are filtered as well.
Let me put an example to clarify.
Imagine a BP with 2 locations: "Location 1" and "Location 2"
And 3 contacts. "contact 1", "contact 2" and "contact 3".
"contact 1" is assigned to the "Location 1" and contact 2 and 3 are not assigned to any location. I'll expect to have only the "contact 1" available with "Location 1" as it is the unique contact assigned to it. And I'd expect as well to not have the "Contact 1" available on "Location 2" as it is assigned to other location.
With your patch we'd get:
"Location 1" - "Contact 1"
"Location 2" - "Contact 1" -> this line should be filtered out
"Location 2" - "Contact 2"
"Location 2" - "Contact 3"
Author: Gorka Ion Damián <gorkaion.damian <at> openbravo.com>
Date: Mon Apr 04 13:01:35 2011 +0200
URL: http://code.openbravo.com/erp/devel/pi/rev/1f6ef3054d8dc7fad9b34a8fed74fe48b072dcde [^]
Fixed issue 16407.Fixed left join constraint.
Thanks for the explanation. I couldn't work out the original reason for the usercontact filter, now that I understand I agree your patch is better :)
It's possible to select the created business partner in the sales order.
|2011-03-22 07:29||eintelau||New Issue|
|2011-03-22 07:29||eintelau||Assigned To||=> alostale|
|2011-03-22 07:29||eintelau||Modules||=> Core|
|2011-03-22 07:45||alostale||Target Version||=> 3.0RC6|
|2011-03-22 07:45||alostale||Status||new => scheduled|
|2011-03-22 07:45||alostale||Assigned To||alostale => iperdomo|
|2011-03-22 07:45||alostale||fix_in_branch||=> pi|
|2011-03-24 09:57||iperdomo||Assigned To||iperdomo => gorkaion|
|2011-04-03 13:19||eintelau||Note Added: 0035496|
|2011-04-03 13:19||eintelau||File Added: 16407.patch|
|2011-04-04 12:21||gorkaion||Note Added: 0035525|
|2011-04-04 13:01||gorkaion||Note Added: 0035536|
|2011-04-04 13:02||hgbot||Note Added: 0035537|
|2011-04-04 13:02||hgbot||Status||scheduled => resolved|
|2011-04-04 13:02||hgbot||Resolution||open => fixed|
|2011-04-04 13:02||hgbot||Fixed in SCM revision||=> http://code.openbravo.com/erp/devel/pi/rev/1f6ef3054d8dc7fad9b34a8fed74fe48b072dcde [^]|
|2011-04-04 14:55||eintelau||Note Added: 0035558|
|2011-04-08 11:29||mirurita||Note Added: 0035758|
|2011-04-08 11:29||mirurita||Status||resolved => closed|
|2011-04-09 00:00||anonymous||sf_bug_id||0 => 3281271|
|Copyright © 2000 - 2009 MantisBT Group|