Hi David, thanks for the time to provide an extensive answer. The problem i have with these fields is actually mostly showing when the communication event is used as an email but also in the other commEvent types.
What you describe below is theoretically completely true, however the reality is different. On an email, the roles of the participants as you describe them, are normally not entered and that is why we have roles like "originator" "recipient" and "carbon copy". Do you state that you are a 'customer' when you write an email to your webshop if you are perhaps also employed by them? I even doubt when the communication event is a phonecall or actually any other event type, even then the 'real' roles are not used.... That is why i said that the info is in the communicationEventRoles. So what do we do, keeping the system OK in theory or do we make it practically working? Regards, Hans On Tue, 2009-03-10 at 01:57 -0600, David E Jones wrote: > 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. > > -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 > > > -- Antwebsystems.com: Quality OFBiz services for competitive rates
