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, 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
--
Antwebsystems.com: Quality OFBiz services for competitive rates
