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
