[ 
http://issues.apache.org/jira/browse/OFBIZ-468?page=comments#action_12450839 ] 
            
Chris Howe commented on OFBIZ-468:
----------------------------------


I think with the various naming conventions that are possible depending on the 
context,  it just goes to show the need for this to be another entity.

However understanding doing that is a much more in depth implementation than 
the benefit derived, I would suggest looking into using CustRequestAttribute to 
shim up this incomplete implementation.  And then using a view entity(ies) to 
make it easy to program with.

This would give you the same output to play with, without adding fields to the 
data model that are implementation specific.

> New CustRequest.primaryContactMechId field to support location of request
> -------------------------------------------------------------------------
>
>                 Key: OFBIZ-468
>                 URL: http://issues.apache.org/jira/browse/OFBIZ-468
>             Project: OFBiz (The Open for Business Project)
>          Issue Type: Improvement
>          Components: order, party
>            Reporter: Si Chen
>         Assigned To: Si Chen
>            Priority: Minor
>
> New CustRequest.primaryContactMechId field to support a location of a cust 
> request--ie, product literature sent to an address, service call at a 
> localtion, etc.
> After some discussion on mailing list and input from David and Chris Howe, I 
> thought long and hard about just adding a contactMechId to CustRequest or 
> adding a whole new CustRequestContactMech entity with different contact mechs 
> per custrequest.  I favor adding just a field as the primary contact mech of 
> the request, as adding an entity is probably an order of magnitude (10x) more 
> complicated: if you had multiple contact mechs per cust request, you will 
> need a whole separate scheme to track if each CustRequestContactMech has been 
> completed, etc., plus the code to create and update addresses becomes much 
> more complicated.  It is easier in most cases just to support it with a 
> hierarchy of CustRequests.
> Following David's recommendation, I am calling it   "primaryContactMechId" 
> instead of just "contactMechId".  If anybody wants to have multiple contact 
> mechs per cust request, they can always improve on this later.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to