[jira] Created: (OFBIZ-468) New CustRequest.primaryContactMech
Locked
[jira] Created: (OFBIZ-468) New CustRequest.primaryContactMech
 
|
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 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 |
[jira] Assigned: (OFBIZ-468) New CustRequest.primaryContactMech
|
|
[ http://issues.apache.org/jira/browse/OFBIZ-468?page=all ]
Si Chen reassigned OFBIZ-468: ----------------------------- Assignee: Si Chen > 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 |
[jira] Commented: (OFBIZ-468) New CustRequest.primaryContactMech
|
|
In reply to this post by Nicolas Malin (Jira)
[ http://issues.apache.org/jira/browse/OFBIZ-468?page=comments#action_12450831 ]
David E. Jones commented on OFBIZ-468: -------------------------------------- Something a little better than "primary" would be nice... with a single ID like that "primary" is kind of implied. If this is for the ContactMech where the request originated, it could be "originContactMechId". If this is the ContactMech where the response should be sent, or where the requester wants to be contacted, then it would be something like "replyToContactMechId" or "noticeContactMechId". > 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 |
[jira] Commented: (OFBIZ-468) New CustRequest.primaryContactMech
|
|
In reply to this post by Nicolas Malin (Jira)
[ 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 |
[jira] Commented: (OFBIZ-468) New CustRequest.primaryContactMech
|
|
In reply to this post by Nicolas Malin (Jira)
[ http://issues.apache.org/jira/browse/OFBIZ-468?page=comments#action_12450885 ]
Si Chen commented on OFBIZ-468: ------------------------------- What's the best word for where the request should be fulfilled? > 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 |
[jira] Commented: (OFBIZ-468) New CustRequest.primaryContactMech
|
|
In reply to this post by Nicolas Malin (Jira)
[ http://issues.apache.org/jira/browse/OFBIZ-468?page=comments#action_12450935 ]
Si Chen commented on OFBIZ-468: ------------------------------- Ok, if nobody has a better idea than how about "fulfillContactMechId" -- basically where the request needs to be fulfilled. So a related modification is in the partymanager's viewprofile.ftl to add a link next to each contact mech with a drop down of all the available CustRequestType's and a button to [Create Request] which would basically create a CustRequest of the custRequestTypeId at that contactMechId to be the fulfillContactMechId. This may involve changing the createCustRequest service to add a contactMechId parameter. > 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 |
[jira] Commented: (OFBIZ-468) New CustRequest.primaryContactMech
|
|
In reply to this post by Nicolas Malin (Jira)
[ http://issues.apache.org/jira/browse/OFBIZ-468?page=comments#action_12450954 ]
David E. Jones commented on OFBIZ-468: -------------------------------------- That sounds fine Si. It is much more specific than "primary". Chris: I think this is fine for now. Creating another entity to relate this would be pretty speculative at this point since we don't really have any set of requirements that would lead to this, that I've seen so far in this discussion or others anyway. > 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 |
[jira] Commented: (OFBIZ-468) New CustRequest.primaryContactMech
|
|
In reply to this post by Nicolas Malin (Jira)
[ 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 |
[jira] Closed: (OFBIZ-468) New CustRequest.primaryContactMech
|
|
In reply to this post by Nicolas Malin (Jira)
[ http://issues.apache.org/jira/browse/OFBIZ-468?page=all ]
Si Chen closed OFBIZ-468. ------------------------- Resolution: Fixed Done in svn r 478277 > 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 |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |