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, jler...@apache.org 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/%3c49ba7a4f.2000...@salmonllc.com%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
