I would like to state that I am currently using the current CommunicationEvent system with no CommunicationEventRole rows being created.
<CommunicationEvent communicationEventId="10000" communicationEventTypeId="PHONE_COMMUNICATION" statusId="COM_IN_PROGRESS" contactMechTypeId="TELECOM_NUMBER" contactMechIdTo="CM-01" roleTypeIdFrom="SALES_REP" roleTypeIdTo="CUSTOMER" partyIdFrom="admin" partyIdTo="PARTY-01" entryDate="2009-02-03 08:27:28.951" subject="Color Choice" content="Asked what color they wanted" note="Asked what color they wanted" /> Does the real issue come up when you have an arbitrary group of parties like in the email example with multiple recipients? Jacques Le Roux wrote: > > From: "David E Jones" <[email protected]> >> >> On Mar 10, 2009, at 1:42 AM, Hans Bakker wrote: >> >>> see below... >>> >>> On Tue, 2009-03-10 at 01:15 -0600, David E Jones wrote: >>>> Aside from it being easier to find the data when they are in these >>>> entity fields (which are always there, don't require a join/view or >>>> additional find, etc), not all of the data is available in the *Role >>>> entity. >>>> >>>> The fields on the CommunicationEvent entity have 3 bits of >>>> information >>>> for each party: >>>> >>>> 1. the fact that it is the from or to party >>>> 2. the ID of the from or to party >>>> 3. the role (like customer, employee, whatever) of the from or to >>>> party >>> >>> that is the exact info in the communicationEventRole.... >> >> How would you model #1 and #3 in CommunicationEventRole? You could >> use a role that specifies from/to (which is a bit of a hack, ie that >> isn't technically a "role"), or you could specify a role that >> describes their actual role. Doing both would require 2 records with >> no way to match them up other than through the partyId... and what >> if other there are other roleTypeIds for that party, etc? >> >> In other words, the structures are NOT equivalent. The biggest issue >> that I have is that for these fields which are common things to >> query by, display, etc it is nice not to have to do a view/join or >> additional query to get the data... >> >> And yes, it would be nice if other's voiced their opinions. BTW, the >> data in these structures should not be duplicated and introduce >> redundancy. If the partyIdFrom/roleTypeIdFrom fields are populated >> the same data should not be in CommunicationEventRole records. > > This the only annoying thing I see in this is. It's the responsability > of the data modeler, but we should make this more clear because it's > not so obvious. Maybe comments in entities definitions ? > > Jacques > >> -David >> >> >>>> On Mar 10, 2009, at 12:56 AM, Hans Bakker wrote: >>>> >>>>> As I said all that data is duplicated in the roles entity... >>>>> the role tells where it comes from, it can more than one destination >>>>> and >>>>> can have many more participants in various other roles..... >>>>> In the case of the communication event it even contains the >>>>> contactMech >>>>> used and status per participant.....vary important in an email >>>>> communication event. >>>>> >>>>> The partyIdTo is even confusing if it was an email send to several >>>>> persons.... >>>>> >>>>> i also do not say it is applicable to other entities, only for >>>>> communication event... >>>>> >>>>> Everywhere the entity Communicationevent is used it needs to it >>>>> replaced >>>>> by the CommunicationEventAndRole view to have the same info..... >>>>> >>>>> anybody else any opinions? >>>>> >>>>> Regards, >>>>> Hans >>>>> >>>>> >>>>> >>>>> On Tue, 2009-03-10 at 00:38 -0600, David E Jones wrote: >>>>>> What about all the other places where this pattern is used, ie >>>>>> where >>>>>> there are partyId and/or roleTypeId fields along with a *Role >>>>>> entity? >>>>>> There are probably dozens of them... >>>>>> >>>>>> The main idea of these is to have the most common, and often >>>>>> necessary, roles represented on the main entity. >>>>>> >>>>>> Also, if we remove these fields how would we know which is the from >>>>>> and to, along with allowing various different roles for the from >>>>>> and >>>>>> to parties? >>>>>> >>>>>> -David >>>>>> >>>>>> >>>>>> On Mar 10, 2009, at 12:11 AM, Hans Bakker wrote: >>>>>> >>>>>>> I would like to propose to depreciate the fields "partyIdFrom and >>>>>>> PartyIdTo and related roles and contact mech in the communication >>>>>>> event. >>>>>>> >>>>>>> All these fields fields are duplicated in the >>>>>>> communicationEventRoles. >>>>>>> >>>>>>> if no objections i will slowly phase them out...first in the >>>>>>> entity >>>>>>> reference and then in forms and screens. >>>>>>> >>>>>>> -- >>>>>>> http://www.antwebsystems.com : >>>>>>> Quality OFBiz support for competitive rates.... >>>>>>> >>>>>> >>>>> -- >>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>> >>>> >>> -- >>> Antwebsystems.com: Quality OFBiz services for competitive rates >>> >> > > > > -- Stephen P Rufle [email protected] H1:480-626-8022 H2:480-802-7173 Yahoo IM: stephen_rufle AOL IM: stephen1rufle
