[ http://issues.apache.org/jira/browse/OFBIZ-468?page=comments#action_12450962 ] Chris Howe commented on OFBIZ-468: ----------------------------------
David, Si, What are your thoughts on the alternative approach that I suggested (CustRequestAttribute along side a view entity). I would prefer this approach as there is already an established manner of relating contact mechs to other entity groups. Since Si's suggestion doesn't follow that approach out of convenience for his specific implementation rather than out of "correctness"/flexibility or some other benefit, I don't see the point in putting a road block in the way for someone who wants to develop it fully which is what adding the field to the entity does (They would need to de-engineer Si's implementation before they engineered their own). Especially since the suggestion wouldn't complicate the development of the feature he's trying to obtain. > 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
