-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am glad to see this. I see this a way to move the to and from in postaladdress as well.
David E Jones sent the following on 3/16/2009 7:43 AM: > > Actually no, I see this new entity as serving a different purpose than > the CommunicationEventRole. There could still be others, like a CSR > Manager or something, that are associated with the CommunicationEvent in > a Role but that were not involved in the communication itself. > > The *Role entities have a general purpose, and I think that general > purpose is still needed for CommunicationEvent... this other just models > who is participating in the communication event itself. > > -David > > > On Mar 16, 2009, at 1:36 AM, Hans Bakker wrote: > >> 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 >> > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJvu4prP3NbaWWqE4RAucGAKDBbKfaIkcB9B998Nnvt7UshdUVwgCcCKRb vQPLb91weOj6+DFQMmwqGFY= =GH3g -----END PGP SIGNATURE-----
