Re: svn commit: r754657 - /ofbiz/trunk/applications/party/entitydef/entitymodel.xml

[hans_bakker]

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?

Regards,
Hans

On Sun, 2009-03-15 at 11:38 +0000, [hidden email] 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.2000101@...%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

[Jacques Le Roux]

This is an interesting use case, I will try...

As you were not the only complainant, I prefered to continue on this subject than letting it orphan. That's why I commited this
comment...

Thanks

Jacques

From: "Hans Bakker" <[hidden email]>

>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?
>
> Regards,
> Hans
>
> On Sun, 2009-03-15 at 11:38 +0000, [hidden email] 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.2000101@...%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
>

[David E Jones-3]

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, [hidden email] 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.2000101@...%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
>

[David E Jones-3]

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, [hidden email] 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.2000101@...%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
>>
>

[hans_bakker]

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, [hidden email] 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.2000101@...%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

[David E Jones-3]

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, [hidden email] 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.2000101@...%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
>

[BJ Freeman]

-----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, [hidden email] 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.2000101@...%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-----

[Bilgin Ibryam]

Hi,

When a controller includes other controllers, all repeating events  
(like preprocessor, postprocessor...) are executed  and there is no  
possibility to override them.

If you want to test, you can go to project manager app with a wrong  
externalLoginKey parameter in the URL and you will see in the console  
that checkExternalLoginKey event from common-controller is executed 6  
times .

To solve this, I propose to add a new attribute called name to "event"  
element in controller. This way if there are events with same names,  
only the last loaded event will be executed.

WDYT?

Bilgin

[Jacques Le Roux]

This sounds like a reasonnable solution to me. There are maybe better, I did not look into details.

Jacques

From: "Bilgin Ibryam" <[hidden email]>

> Hi,
>
> When a controller includes other controllers, all repeating events  
> (like preprocessor, postprocessor...) are executed  and there is no  
> possibility to override them.
>
> If you want to test, you can go to project manager app with a wrong  
> externalLoginKey parameter in the URL and you will see in the console  
> that checkExternalLoginKey event from common-controller is executed 6  
> times .
>
> To solve this, I propose to add a new attribute called name to "event"  
> element in controller. This way if there are events with same names,  
> only the last loaded event will be executed.
>
> WDYT?
>
> Bilgin
>

[Adrian Crum]

It would be better to fix the Java code that reads the XML files so this
doesn't happen.

-Adrian

Jacques Le Roux wrote:

> This sounds like a reasonnable solution to me. There are maybe better, I
> did not look into details.
>
> Jacques
>
> From: "Bilgin Ibryam" <[hidden email]>
>> Hi,
>>
>> When a controller includes other controllers, all repeating events  
>> (like preprocessor, postprocessor...) are executed  and there is no  
>> possibility to override them.
>>
>> If you want to test, you can go to project manager app with a wrong  
>> externalLoginKey parameter in the URL and you will see in the console  
>> that checkExternalLoginKey event from common-controller is executed 6  
>> times .
>>
>> To solve this, I propose to add a new attribute called name to
>> "event"  element in controller. This way if there are events with same
>> names,  only the last loaded event will be executed.
>>
>> WDYT?
>>
>> Bilgin
>>
>
>

[Bilgin Ibryam]

On Mar 17, 2009, at 4:31 PM, Adrian Crum wrote:

> It would be better to fix the Java code that reads the XML files so  
> this doesn't happen.

Yes thats true, but I still think we need also a way for overriding  
the events as it is with request, views, handlers...
How can I use a custom event instead of the one defined in common-
controller?

[Stephen Rufle-2]

>
> 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):

I was following
http://www.nabble.com/depreciate-fields-td22428632.html

Where did you explain the introduction CommunicationEventContactMech .

[BJ Freeman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

found this
http://www.mail-archive.com/ofbiz-dev@.../msg00388.html
however I don't see it in the trunk and have no history where it went.

Stephen Rufle sent the following on 3/17/2009 9:28 AM:

>> 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):
>
> I was following
> http://www.nabble.com/depreciate-fields-td22428632.html
>
> Where did you explain the introduction CommunicationEventContactMech .
>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJv9uSrP3NbaWWqE4RAgFEAJ452Ocp7arJPZb2MSsPHXZHUJq6xwCgyWa6
X/nldFTn+P87lxxc0n7IWeI=
=y1uS
-----END PGP SIGNATURE-----

[Stephen Rufle-2]

Yeah I saw the same issue when I googled, I noticed that 665 is
something different on https://issues.apache.org/jira/browse/OFBIZ

the one in the archive is from undersunconsulting, so I think some one
would have had to import all the issues which may have renumbered them.
http://jira.undersunconsulting.com/browse

I am interested in this issue because as stated on the user list I am
currently using CommunicationEvent and setting roleTypeFrom=SALES_REP
and roleTypeTo = CUSTOMER

When I was reading the thread, before I git to David's suggestion of
CommunicationEventContactMech I also thought maybe teh Entity needs to
be split for only certain type or Communication.

BJ Freeman wrote:

> found this
> http://www.mail-archive.com/ofbiz-dev@.../msg00388.html
> however I don't see it in the trunk and have no history where it went.
>
> Stephen Rufle sent the following on 3/17/2009 9:28 AM:
> >> 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):
> > I was following
> > http://www.nabble.com/depreciate-fields-td22428632.html
>
> > Where did you explain the introduction CommunicationEventContactMech .
>
>
>

--
Stephen P Rufle
[hidden email]
H1:480-626-8022
H2:480-802-7173
Yahoo IM: stephen_rufle
AOL IM: stephen1rufle

[David E Jones-3]

On Mar 17, 2009, at 9:08 AM, Bilgin Ibryam wrote:

>
> On Mar 17, 2009, at 4:31 PM, Adrian Crum wrote:
>
>> It would be better to fix the Java code that reads the XML files so  
>> this doesn't happen.
>
> Yes thats true, but I still think we need also a way for overriding  
> the events as it is with request, views, handlers...
> How can I use a custom event instead of the one defined in common-
> controller?
>

One way or another I agree we should fix the code so that if there is  
a duplicate event (ie same location and same invoke) then we should  
only run it once.

As for overriding... that is why I originally wrote this so that if  
you had a "preprocessor" (or whatever) tag at all then the included  
preprocessor events would disappear and be replaced by your own.  
However, that involved getting rid of all of the events from the  
included controller.

A name or some sort of an identifier on each might be a good way to  
go...

-David

[Bilgin Ibryam]

On Mar 17, 2009, at 10:55 PM, David E Jones wrote:

> A name or some sort of an identifier on each might be a good way to  
> go...
>
> -David


David, thanks for the advice.
Do you mean a new optional "name" attribute on event element, so that  
events with the same name (inside firstvisin, preprocessor... ) will  
be overridden ?
Or you mean a new "name" attribute on firstvisin/preprocessor/
postprocessor.... elements so we will be able to replace all the  
events inside these elements at once?

[David E Jones-3]

On Apr 1, 2009, at 3:13 AM, Bilgin Ibryam wrote:

>
> On Mar 17, 2009, at 10:55 PM, David E Jones wrote:
>
>> A name or some sort of an identifier on each might be a good way to  
>> go...
>>
>> -David
>
>
> David, thanks for the advice.
> Do you mean a new optional "name" attribute on event element, so  
> that events with the same name (inside firstvisin, preprocessor... )  
> will be overridden ?

Yes, that is what I meant.

> Or you mean a new "name" attribute on firstvisin/preprocessor/
> postprocessor.... elements so we will be able to replace all the  
> events inside these elements at once?

This would be more or less the same as just overriding the entire  
block all the time, ie probably not as useful.

-David

[Bilgin Ibryam]

On Apr 1, 2009, at 12:24 PM, David E Jones wrote:

>
> On Apr 1, 2009, at 3:13 AM, Bilgin Ibryam wrote:
>
>>
>> On Mar 17, 2009, at 10:55 PM, David E Jones wrote:
>>
>>> A name or some sort of an identifier on each might be a good way  
>>> to go...
>>>
>>> -David
>>
>>
>> David, thanks for the advice.
>> Do you mean a new optional "name" attribute on event element, so  
>> that events with the same name (inside firstvisin,  
>> preprocessor... ) will be overridden ?
>
> Yes, that is what I meant.

OK, then I will add an optional name attribute. Optional because this  
attribute will not be used in request events.

Bilgin

>
>
>> Or you mean a new "name" attribute on firstvisin/preprocessor/
>> postprocessor.... elements so we will be able to replace all the  
>> events inside these elements at once?
>
> This would be more or less the same as just overriding the entire  
> block all the time, ie probably not as useful.
>
> -David
>

[Scott Gray-2]

Another approach could be to add a disable attribute to the event element, that way you could just disable an event by redefining it with disabled="true" and then you could either define a new event or not depending on what you were trying to achieve, WDYT?

Regards

Scott

HotWax Media

http://www.hotwaxmedia.com

On 1/04/2009, at 10:52 PM, Bilgin Ibryam wrote:

On Apr 1, 2009, at 12:24 PM, David E Jones wrote:

On Apr 1, 2009, at 3:13 AM, Bilgin Ibryam wrote:

On Mar 17, 2009, at 10:55 PM, David E Jones wrote:

A name or some sort of an identifier on each might be a good way to go...

-David

David, thanks for the advice.

Do you mean a new optional "name" attribute on event element, so that events with the same name (inside firstvisin, preprocessor... ) will be overridden ?

Yes, that is what I meant.

OK, then I will add an optional name attribute. Optional because this attribute will not be used in request events.

Bilgin

Or you mean a new "name" attribute on firstvisin/preprocessor/postprocessor.... elements so we will be able to replace all the events inside these elements at once?

This would be more or less the same as just overriding the entire block all the time, ie probably not as useful.

-David

[Bilgin Ibryam]

Done in r761220

On Apr 1, 2009, at 12:24 PM, David E Jones wrote:

>
> On Apr 1, 2009, at 3:13 AM, Bilgin Ibryam wrote:
>
>>
>> On Mar 17, 2009, at 10:55 PM, David E Jones wrote:
>>
>>> A name or some sort of an identifier on each might be a good way  
>>> to go...
>>>
>>> -David
>>
>>
>> David, thanks for the advice.
>> Do you mean a new optional "name" attribute on event element, so  
>> that events with the same name (inside firstvisin,  
>> preprocessor... ) will be overridden ?
>
> Yes, that is what I meant.
>
>> Or you mean a new "name" attribute on firstvisin/preprocessor/
>> postprocessor.... elements so we will be able to replace all the  
>> events inside these elements at once?
>
> This would be more or less the same as just overriding the entire  
> block all the time, ie probably not as useful.
>
> -David
>