Hi David, Sometimes one has to oversimplify to get a ball rolling..... Thank you for now acknowledging that the current communication event model has its problems. This new entity as you describe below is indeed a better solution than the CommunicationEventRole entity and allows for the usage of the communicationevent in all the cases I see. We can now remove the roletypes as 'originator', 'recipient' etc...
If i understand you well, then you will propose that this new entity will replace the communicationEventRole entity? And how is the from/to data in the communicationevent now relate to this new entity? Can they now be depreciated? so finally Jacques succeeded to get this slowly resolved.... :-) Regards, Hans On Sun, 2009-03-15 at 12:04 -0600, David E Jones wrote: > Since we seem to be back to this issue... > > What you're saying Hans is an over-simplification of the issue as I > explained before. > > If you want to properly model the from/to situation we need an entity > like this (as I also explained before, so see that email for rationale > and other details): > > CommunicationEventContactMech > communicationEventId* > contactMechId* > contactTypeEnumId* > partyId > roleTypeId > > Notice that partyId and roleTypeId are NOT part of the PK and are > intentionally optional. In many cases all you'll have is an email > address and you won't know a party or a role. > > The contactTypeEnumId would have options for email comm events like > "TO", "FROM", "CC", and "BCC". > > IMO anything other than this is an over-simplification and does not > adequately model the problem. > > However, that is based only on the requirements that I came up with... > but since no one else has tried to come up with requirements for this > data model (only saying this or that design is the way to go)... there > it is. > > -David > > > On Mar 15, 2009, at 11:57 AM, David E Jones wrote: > > > > > On Mar 15, 2009, at 7:09 AM, Hans Bakker wrote: > > > >> I am sorry but i do not agree with this. > >> The roleTypes on a communication event is a big problem. > >> > >> did you ever send an email stating you are a customer or an employee? > >> You do however know if you are the originator and which parties you > >> copy...and the parties you copy...which roleTypes do they have? > > > > Send personally? No. Send from an organization? Usually. Receive in > > an organization? Yes. > > > > When an organization receives communication it is nice to know who > > it is from and what role they are playing. For example later on one > > might want to report on communications from customers without > > including communications from suppliers or employees or whomever. > > > > -David > > > > > >> On Sun, 2009-03-15 at 11:38 +0000, [email protected] wrote: > >>> Author: jleroux > >>> Date: Sun Mar 15 11:38:29 2009 > >>> New Revision: 754657 > >>> > >>> URL: http://svn.apache.org/viewvc?rev=754657&view=rev > >>> Log: > >>> Descriptions enhancements from the thread > >>> http://mail-archives.apache.org/mod_mbox/ofbiz-user/200903.mbox/%[email protected]%3e > >>> > >>> Modified: > >>> ofbiz/trunk/applications/party/entitydef/entitymodel.xml > >>> > >>> Modified: ofbiz/trunk/applications/party/entitydef/entitymodel.xml > >>> URL: > >>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/party/entitydef/entitymodel.xml?rev=754657&r1=754656&r2=754657&view=diff > >>> = > >>> = > >>> = > >>> = > >>> = > >>> = > >>> = > >>> = > >>> = > >>> = > >>> ==================================================================== > >>> --- ofbiz/trunk/applications/party/entitydef/entitymodel.xml > >>> (original) > >>> +++ ofbiz/trunk/applications/party/entitydef/entitymodel.xml Sun > >>> Mar 15 11:38:29 2009 > >>> @@ -647,7 +647,7 @@ > >>> <field name="contactMechTypeId" type="id"></field> > >>> <field name="contactMechIdFrom" type="id"/> > >>> <field name="contactMechIdTo" type="id"/> > >>> - <field name="roleTypeIdFrom" type="id"></field> > >>> + <field name="roleTypeIdFrom" type="id"><description>If > >>> the partyIdFrom/roleTypeIdFrom fields are populated here the same > >>> data should not be duplicated in CommunicationEventRole records.</ > >>> description></field> > >>> <field name="roleTypeIdTo" type="id"></field> > >>> <field name="partyIdFrom" type="id"></field> > >>> <field name="partyIdTo" type="id"></field> > >>> @@ -842,7 +842,7 @@ > >>> package-name="org.ofbiz.party.communication" > >>> title="Communication Event Role Entity"> > >>> <field name="communicationEventId" type="id-ne"></field> > >>> - <field name="partyId" type="id-ne"></field> > >>> + <field name="partyId" type="id-ne"><description>If the > >>> partyIdFrom/roleTypeIdFrom fields are populated in > >>> CommunicationEvent the same data should not be duplicated in > >>> CommunicationEventRole records.</description></field> > >>> <field name="roleTypeId" type="id-ne"></field> > >>> <field name="contactMechId" type="id"><description>For > >>> additional communication event participants this represents the > >>> contactMechId of the ContactMech used.</description></field> > >>> <field name="statusId" type="id"></field> > >>> > >>> > >> -- > >> Antwebsystems.com: Quality OFBiz services for competitive rates > >> > > > -- Antwebsystems.com: Quality OFBiz services for competitive rates
