Dev - associating communication events with various things

[Si Chen-2]

Hi everybody.

What is the best way to start associating communication events (letters,
emails, phone calls, etc.) with Orders, Quotes, Requests, etc. etc.?  
Should we just add fields like orderId, quoteId, etc. to
CommunicationEvent?  Should we create more entities like
CustRequestCommEvent?  Or should everything go through WorkEffort?

Thanks!

Si
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

I'll get to this questions in a bit, but first a quick comment on the  
related commit in rev 6485: Creating new ContactMech records for  
these shouldn't be necessary if they are straight copies.  
ContactMechs are (or _should_ be for all code written) considered  
immutable. That is why the update services make new contact mechs  
rather than updating existing records, and then associate the new  
ones with the party that the change was requested for. So, other  
parties, orders, facilities, and so on even if pointing to the same  
original contact mech would not be changed, which is the whole point.

So, when associating a ContactMech with another party the only record  
needed is a new PartyContactMech, and possible some  
PartyContactMechPurpose records.

-David


On Jan 9, 2006, at 3:26 PM, Si Chen wrote:

> Hi everybody.
>
> What is the best way to start associating communication events  
> (letters,
> emails, phone calls, etc.) with Orders, Quotes, Requests, etc. etc.?
> Should we just add fields like orderId, quoteId, etc. to
> CommunicationEvent?  Should we create more entities like
> CustRequestCommEvent?  Or should everything go through WorkEffort?
>
> Thanks!
>
> Si
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

Hi David,

The actual requirement here was that the new party would start out with
the same contact mech, but its contact mechs are independent and can
change without affecting the original party.  Thus, if the contact mech
of the new party is modified later, the old party's does not change at
the same time.

Si

David E. Jones wrote:

>
> I'll get to this questions in a bit, but first a quick comment on the  
> related commit in rev 6485: Creating new ContactMech records for  
> these shouldn't be necessary if they are straight copies.  
> ContactMechs are (or _should_ be for all code written) considered  
> immutable. That is why the update services make new contact mechs  
> rather than updating existing records, and then associate the new  
> ones with the party that the change was requested for. So, other  
> parties, orders, facilities, and so on even if pointing to the same  
> original contact mech would not be changed, which is the whole point.
>
> So, when associating a ContactMech with another party the only record  
> needed is a new PartyContactMech, and possible some  
> PartyContactMechPurpose records.
>
> -David
>
>
> On Jan 9, 2006, at 3:26 PM, Si Chen wrote:
>
>> Hi everybody.
>>
>> What is the best way to start associating communication events  
>> (letters,
>> emails, phone calls, etc.) with Orders, Quotes, Requests, etc. etc.?
>> Should we just add fields like orderId, quoteId, etc. to
>> CommunicationEvent?  Should we create more entities like
>> CustRequestCommEvent?  Or should everything go through WorkEffort?
>>
>> Thanks!
>>
>> Si
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
>
>------------------------------------------------------------------------
>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

David,

While I got you on the line, this is something I've been thinking of for
a while: how should we identify what the content type of a
CommunicationEvent should be?

My initial need is just to specify plain text vs text/html email, but I
could see eventually storing all sorts of things (letters, PDFs, etc. )
as CommunicationEvents.  Should we use some of the fields in the Content
application?  If so, which ones?  (Sorry I'm not too familiar with all
the work going on there.)

Si

>>On Jan 9, 2006, at 3:26 PM, Si Chen wrote:
>>
>>    
>>
>>>Hi everybody.
>>>
>>>What is the best way to start associating communication events  
>>>(letters,
>>>emails, phone calls, etc.) with Orders, Quotes, Requests, etc. etc.?
>>>Should we just add fields like orderId, quoteId, etc. to
>>>CommunicationEvent?  Should we create more entities like
>>>CustRequestCommEvent?  Or should everything go through WorkEffort?
>>>
>>>Thanks!
>>>
>>>Si
>>>
>>>_______________________________________________
>>>Dev mailing list
>>>[hidden email]
>>>http://lists.ofbiz.org/mailman/listinfo/dev
>>>      
>>>
>>------------------------------------------------------------------------
>>
>>
>>_______________________________________________
>>Dev mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/dev
>>
>>    
>>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Maybe what I said wasn't clear... ContactMechs are immutable  
(unchangeable). That means that if another party refers to the _same_  
contractMechId it won't matter if either changes it, the other party  
won't see the changes. If you create a new ContactMech when copying  
it over to a new party, and then the ContactMech is changed for the  
new party all the update service will do is make yet another copy...  
So, the first copy is not necessary.

-David


On Jan 9, 2006, at 4:11 PM, Si Chen wrote:

> Hi David,
>
> The actual requirement here was that the new party would start out  
> with
> the same contact mech, but its contact mechs are independent and can
> change without affecting the original party.  Thus, if the contact  
> mech
> of the new party is modified later, the old party's does not change at
> the same time.
>
> Si
>
> David E. Jones wrote:
>
>>
>> I'll get to this questions in a bit, but first a quick comment on the
>> related commit in rev 6485: Creating new ContactMech records for
>> these shouldn't be necessary if they are straight copies.
>> ContactMechs are (or _should_ be for all code written) considered
>> immutable. That is why the update services make new contact mechs
>> rather than updating existing records, and then associate the new
>> ones with the party that the change was requested for. So, other
>> parties, orders, facilities, and so on even if pointing to the same
>> original contact mech would not be changed, which is the whole point.
>>
>> So, when associating a ContactMech with another party the only record
>> needed is a new PartyContactMech, and possible some
>> PartyContactMechPurpose records.
>>
>> -David
>>
>>
>> On Jan 9, 2006, at 3:26 PM, Si Chen wrote:
>>
>>> Hi everybody.
>>>
>>> What is the best way to start associating communication events
>>> (letters,
>>> emails, phone calls, etc.) with Orders, Quotes, Requests, etc. etc.?
>>> Should we just add fields like orderId, quoteId, etc. to
>>> CommunicationEvent?  Should we create more entities like
>>> CustRequestCommEvent?  Or should everything go through WorkEffort?
>>>
>>> Thanks!
>>>
>>> Si
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>>
>> ---------------------------------------------------------------------
>> ---
>>
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

You're right!  New version coming soon.  Thanks for pointing this out.

Si

David E. Jones wrote:

>
> Maybe what I said wasn't clear... ContactMechs are immutable  
> (unchangeable). That means that if another party refers to the _same_  
> contractMechId it won't matter if either changes it, the other party  
> won't see the changes. If you create a new ContactMech when copying  
> it over to a new party, and then the ContactMech is changed for the  
> new party all the update service will do is make yet another copy...  
> So, the first copy is not necessary.
>
> -David
>
>
> On Jan 9, 2006, at 4:11 PM, Si Chen wrote:
>
>> Hi David,
>>
>> The actual requirement here was that the new party would start out  with
>> the same contact mech, but its contact mechs are independent and can
>> change without affecting the original party.  Thus, if the contact  mech
>> of the new party is modified later, the old party's does not change at
>> the same time.
>>
>> Si
>>
>> David E. Jones wrote:
>>
>>>
>>> I'll get to this questions in a bit, but first a quick comment on the
>>> related commit in rev 6485: Creating new ContactMech records for
>>> these shouldn't be necessary if they are straight copies.
>>> ContactMechs are (or _should_ be for all code written) considered
>>> immutable. That is why the update services make new contact mechs
>>> rather than updating existing records, and then associate the new
>>> ones with the party that the change was requested for. So, other
>>> parties, orders, facilities, and so on even if pointing to the same
>>> original contact mech would not be changed, which is the whole point.
>>>
>>> So, when associating a ContactMech with another party the only record
>>> needed is a new PartyContactMech, and possible some
>>> PartyContactMechPurpose records.
>>>
>>> -David
>>>
>>>
>>> On Jan 9, 2006, at 3:26 PM, Si Chen wrote:
>>>
>>>> Hi everybody.
>>>>
>>>> What is the best way to start associating communication events
>>>> (letters,
>>>> emails, phone calls, etc.) with Orders, Quotes, Requests, etc. etc.?
>>>> Should we just add fields like orderId, quoteId, etc. to
>>>> CommunicationEvent?  Should we create more entities like
>>>> CustRequestCommEvent?  Or should everything go through WorkEffort?
>>>>
>>>> Thanks!
>>>>
>>>> Si
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [hidden email]
>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> ---
>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
>
>------------------------------------------------------------------------
>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev