Dev - CommEvent glue for Product and Order
Locked
Dev - CommEvent glue for Product and Order
 
|
Re: Dev - CommEvent glue for Product and Order
|
|
Re: Dev - CommEvent glue for Product and Order
|
|
David,
Thanks for the advice. In this case, the client needs both entities. I have changed the entity names as you suggested (still not sure about the group). Should these be added to OFBiz or should we just make them a part of this custom project? We will be adding services to attach CommunciationEvents to Product and Order, as well. I have attached those diff files. -Al David E. Jones wrote: >Al, > >As with all fields the *TypeId fields are only needed when there is a reason for them. In the case of type fields it is when there is more than one type of relationship between the associated entities is needed. If the different types are vital to the relationship and there is a possibility that more than one type will apply to 2 specific records, then it needs to be part of the primary key. > >This goes for the "description" fields as well. There should be a reason for them, and in the case of these 2 entities I'm not sure what the reason would be. > >In fact I'm not sure what the purpose in general for these entities would be. To denote that a product or order was discussed during a communication event? In many cases those should be associated not directly to the CommunicationEvent but rather to a CustRequest associated with the CommunicationEvent because any sort of customer service or support request/issue is likely to cover multiple CommunicationEvents. The trick is always looking at expected processes and what needs to be tracked in them, and to do so from a global perspective before decided which fields will go on which entity and which entities are needed and how they will be related to each other. > >The names for these should probably be reversed as well, ie CommunicationEventOrder. The reason for this is that the Party and related entities are "lower level" than the Order and Product and related entities. > >-David > > >Al Byers wrote: > > >>I am coding an app in which it is desired to attach CommunicationEvents >>to Product and Order. This seems to follow pattern mentioned in >>http://jira.undersunconsulting.com/browse/OFBIZ-665. >> >>Are these entitydefs below appropriate? >> >>These were taken from CommunicationEventWorkEff and there is no type >>field in that entity. What is the reasoning behind when to include a >>commEventWorkEffTypeId field and when not? >> >> >>-Al >> >> <entity-group group="org.ofbiz" entity="OrderCommunicationEvent" /> >> >> <entity entity-name="OrderCommunicationEvent" >> package-name="org.ofbiz.order.order" >> title="Order Communication Event Entity"> >> <field name="orderId" type="id-ne"></field> >> <field name="communicationEventId" type="id-ne"></field> >> <field name="description" type="description"></field> >> <prim-key field="orderId"/> >> <prim-key field="communicationEventId"/> >> <relation type="one" fk-name="ORDER_COMEV_ORDER" >>rel-entity-name="Order"> >> <key-map field-name="orderId"/> >> </relation> >> <relation type="one" fk-name="ORDER_COMEV_CMEV" >>rel-entity-name="CommunicationEvent"> >> <key-map field-name="communicationEventId"/> >> </relation> >> </entity> >> >> <entity-group group="org.ofbiz" entity="ProductCommunicationEvent" /> >> >> <entity entity-name="ProductCommunicationEvent" >> package-name="org.ofbiz.product.product" >> title="Product Communication Event Entity"> >> <field name="productId" type="id-ne"></field> >> <field name="communicationEventId" type="id-ne"></field> >> <field name="description" type="description"></field> >> <prim-key field="productId"/> >> <prim-key field="communicationEventId"/> >> <relation type="one" fk-name="PROD_COMEV_PROD" >>rel-entity-name="Product"> >> <key-map field-name="productId"/> >> </relation> >> <relation type="one" fk-name="PROD_COMEV_CMEV" >>rel-entity-name="CommunicationEvent"> >> <key-map field-name="communicationEventId"/> >> </relation> >> </entity> >> >> >>_______________________________________________ >>Dev mailing list >>[hidden email] >>http://lists.ofbiz.org/mailman/listinfo/dev >> >> > >_______________________________________________ >Dev mailing list >[hidden email] >http://lists.ofbiz.org/mailman/listinfo/dev > > > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
commevent.zip (1K)
Re: Dev - CommEvent glue for Product and Order
|
|
Might help if the entity defs were tested and right.
-Al Al Byers wrote: > David, > > Thanks for the advice. In this case, the client needs both entities. I > have changed the entity names as you suggested (still not sure about > the group). Should these be added to OFBiz or should we just make them > a part of this custom project? > > We will be adding services to attach CommunciationEvents to Product > and Order, as well. > > I have attached those diff files. > > -Al > > David E. Jones wrote: > >> Al, >> >> As with all fields the *TypeId fields are only needed when there is a >> reason for them. In the case of type fields it is when there is more >> than one type of relationship between the associated entities is >> needed. If the different types are vital to the relationship and >> there is a possibility that more than one type will apply to 2 >> specific records, then it needs to be part of the primary key. >> >> This goes for the "description" fields as well. There should be a >> reason for them, and in the case of these 2 entities I'm not sure >> what the reason would be. >> >> In fact I'm not sure what the purpose in general for these entities >> would be. To denote that a product or order was discussed during a >> communication event? In many cases those should be associated not >> directly to the CommunicationEvent but rather to a CustRequest >> associated with the CommunicationEvent because any sort of customer >> service or support request/issue is likely to cover multiple >> CommunicationEvents. The trick is always looking at expected >> processes and what needs to be tracked in them, and to do so from a >> global perspective before decided which fields will go on which >> entity and which entities are needed and how they will be related to >> each other. >> >> The names for these should probably be reversed as well, ie >> CommunicationEventOrder. The reason for this is that the Party and >> related entities are "lower level" than the Order and Product and >> related entities. >> >> -David >> >> >> Al Byers wrote: >> >> >>> I am coding an app in which it is desired to attach >>> CommunicationEvents to Product and Order. This seems to follow >>> pattern mentioned in >>> http://jira.undersunconsulting.com/browse/OFBIZ-665. >>> >>> Are these entitydefs below appropriate? >>> >>> These were taken from CommunicationEventWorkEff and there is no type >>> field in that entity. What is the reasoning behind when to include a >>> commEventWorkEffTypeId field and when not? >>> >>> >>> -Al >>> >>> <entity-group group="org.ofbiz" entity="OrderCommunicationEvent" /> >>> >>> <entity entity-name="OrderCommunicationEvent" >>> package-name="org.ofbiz.order.order" >>> title="Order Communication Event Entity"> >>> <field name="orderId" type="id-ne"></field> >>> <field name="communicationEventId" type="id-ne"></field> >>> <field name="description" type="description"></field> >>> <prim-key field="orderId"/> >>> <prim-key field="communicationEventId"/> >>> <relation type="one" fk-name="ORDER_COMEV_ORDER" >>> rel-entity-name="Order"> >>> <key-map field-name="orderId"/> >>> </relation> >>> <relation type="one" fk-name="ORDER_COMEV_CMEV" >>> rel-entity-name="CommunicationEvent"> >>> <key-map field-name="communicationEventId"/> >>> </relation> >>> </entity> >>> >>> <entity-group group="org.ofbiz" >>> entity="ProductCommunicationEvent" /> >>> >>> <entity entity-name="ProductCommunicationEvent" >>> package-name="org.ofbiz.product.product" >>> title="Product Communication Event Entity"> >>> <field name="productId" type="id-ne"></field> >>> <field name="communicationEventId" type="id-ne"></field> >>> <field name="description" type="description"></field> >>> <prim-key field="productId"/> >>> <prim-key field="communicationEventId"/> >>> <relation type="one" fk-name="PROD_COMEV_PROD" >>> rel-entity-name="Product"> >>> <key-map field-name="productId"/> >>> </relation> >>> <relation type="one" fk-name="PROD_COMEV_CMEV" >>> rel-entity-name="CommunicationEvent"> >>> <key-map field-name="communicationEventId"/> >>> </relation> >>> </entity> >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [hidden email] >>> http://lists.ofbiz.org/mailman/listinfo/dev >>> >> >> >> _______________________________________________ >> Dev mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/dev >> >> >> > >------------------------------------------------------------------------ > > >_______________________________________________ >Dev mailing list >[hidden email] >http://lists.ofbiz.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Dev - timekeeping
|
|
Dev - Financials
|
|
Re: Dev - timekeeping
|
|
Re: Dev - timekeeping
|
|
Re: Dev - Financials
|
|
Re: Dev - Financials
|
|
| Free forum by Nabble | Edit this page |