depreciate fields
Locked
 
|
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.... |
|
|
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.... > |
|
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 |
|
|
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 -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 > |
|
|
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.... > > -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 |
|
|
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 > |
|
|
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 |
|
|
On Mar 10, 2009, at 2:53 AM, Hans Bakker wrote: > 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. That there's what I like to call a "logic trap". > 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". If we were to model this information literally I wouldn't recommend using the CommunicationEventRole entity, as it means something different. What you are describing here is the addresses on the email, and perhaps the Party for each (if there is a Party for the given address in the system). In that case an email address (a contactMechId) would be required and part of the PK but the partyId would be optional, and not part of the PK. That doesn't sound like a CommunicationEventRole to me... > Do you state that you are a 'customer' > when you write an email to your webshop if you are perhaps also > employed > by them? Even more the need for identifying the role for that particular communication. It can be helpful to know that a party that is both a customer and an employee is acting as a customer or employee for a particular communication. > 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? Yeah, back to the "logic trap". The implied assumption is that using the CommunicationEventRole entity is the only practical solution. If you start from there chances are you'll end up there, hence the term "logic trap". It's helpful to talk about specific data you want to model, as you started to above and that I tried to communicate back to you and expand a bit there. If that isn't what you're trying to model, we should maybe start with establishing what it is that you're trying to model and then come up with the best structure for it, perhaps an existing one and perhaps not. -David > 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 > |
|
|
In reply to this post by David E Jones-3
see below
David E Jones escribió: > > 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? types of COMMUNICATION EVENT ROLES TYPEs are valid for what types of CONTACT MECHANISM TYPEs. For instance, a "caller" and "receiver" may be valid for a "phone" contact mechanism type, while "facilitator", "participant", and "note taker" are valid roles for a "face-to-face communication." (...)" So, CALLER and RECEIVER will be valid roles for a phone call. And a mail can have multiple RECEIVERS. And in a P2P comm you would have multiple SENDERS and multiple RECEIVERS ;) It may be that the problem here is that there is confusion between party roles and communication event roles. In the book they are in different entities but it is not like that in OfBiz. I.e. that CALLER and RECEIVER need not to be valid roles for the parties involved in the communication event. In short, I agree with Hans :) -- Daniel Martínez > > 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 >> > -- ------------------------------------------------------------------------ Soluciones de Gestión para su empresa eBusiness, ERP, CRM ------------------------------------------------------------------------ *Daniel Martínez Martínez* *Gerente *C/ Julia García Boután, 29 28022 Madrid España E-mail: [hidden email] <mailto:[hidden email]> Web: *www.paradisosistemas.es <http://www.paradisosistemas.es/> *Comercial: [hidden email] <mailto:[hidden email]> Tel: 678416758 |
Administrator
|
In reply to this post by David E Jones-3
From: "David E Jones" <[hidden email]> > > 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 >> > |
|
|
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" <[hidden email]> >> >> 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 [hidden email] H1:480-626-8022 H2:480-802-7173 Yahoo IM: stephen_rufle AOL IM: stephen1rufle |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |