Dev - all my comm event questions

[Si Chen-2]

Hi David,

I thought it'd be helpful if I put everything on one email for you:

1.  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?

2.  How should we identify what the content type of a
CommunicationEvent should be?  Should we add the mimeTypeId field to CommunicationEvent?  Should we add the other contentTypeId field?

3.  How do we associate certain communication events with the right contact mechs, so the system would know, for example, that a phone call can be made to a phone #, an email can be sent to an email address, and a letter is at a postal address?  I think it is safer to create a new associations entity, CommEventContactMechAssoc, because some comm events can happen at different contact mech types (ie, a meeting can take place over the phone or at a postal address.)

Thanks,

Si

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

[byersa]

Si,

I am interested in David's reply, but I have some input on #2. I wonder
if when there is this need to start incorporating Content-related fields
in the CommunicationEvent, if it would not be worthwhile considering
tying the CommunicationEvents to a Content entity via a "contentId"
field. This could be done in an either/or fashion with the current
"content" field. The data would actually be handled by the DataResource
entity's mimeTypeId and characterSetId fields. I could add a new
dataResourceTypeId value of, "COMM_EVENT", so that the content manager
knows how to access the CommunicationEvent's content field, if you
wanted to use it.

This is still a little muddy in my head, but some of the reasons for
considering this would be related to the facilities that will be
available in the CMS as it matures. These would include automatic search
indexing and the ability to treat the communication as a "blog" entry,
to which, qualified users could add comments, notes or instructions.

It would also work the other way - what if you wanted to send the same
communication to a number of parties. By referencing a single contentId,
you would not have to have duplicate information in the "content" field
of all those CommunicationEvent entities.

-Al

Si Chen wrote:

>Hi David,
>
>I thought it'd be helpful if I put everything on one email for you:
>
>1.  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?
>
>2.  How should we identify what the content type of a
>CommunicationEvent should be?  Should we add the mimeTypeId field to CommunicationEvent?  Should we add the other contentTypeId field?
>
>3.  How do we associate certain communication events with the right contact mechs, so the system would know, for example, that a phone call can be made to a phone #, an email can be sent to an email address, and a letter is at a postal address?  I think it is safer to create a new associations entity, CommEventContactMechAssoc, because some comm events can happen at different contact mech types (ie, a meeting can take place over the phone or at a postal address.)
>
>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]

Al,

I think you are right.  It is the only way to solve problems like how to
create different types of content, attachments, and so forth.

So should we follow the Product pattern, where there were override
fields are on the CommEvent entity itself, and then there is a
CommEventContent entity which is like the ProductContent entity?

Also, can you give me a quick review - what are the high level API
methods required to create Contents for a CommEvent.  For example, here
are some use cases:
1.  Create a MIME type email, and I need to invoke the browser HTML
editor in OFBIZ right now.
2.  Create a mass email based on a template
3.  Create a comm event with some attachments (ie, PDFs or pictures)

Thanks!

Si

Al Byers wrote:

>Si,
>
>I am interested in David's reply, but I have some input on #2. I wonder
>if when there is this need to start incorporating Content-related fields
>in the CommunicationEvent, if it would not be worthwhile considering
>tying the CommunicationEvents to a Content entity via a "contentId"
>field. This could be done in an either/or fashion with the current
>"content" field. The data would actually be handled by the DataResource
>entity's mimeTypeId and characterSetId fields. I could add a new
>dataResourceTypeId value of, "COMM_EVENT", so that the content manager
>knows how to access the CommunicationEvent's content field, if you
>wanted to use it.
>
>This is still a little muddy in my head, but some of the reasons for
>considering this would be related to the facilities that will be
>available in the CMS as it matures. These would include automatic search
>indexing and the ability to treat the communication as a "blog" entry,
>to which, qualified users could add comments, notes or instructions.
>
>It would also work the other way - what if you wanted to send the same
>communication to a number of parties. By referencing a single contentId,
>you would not have to have duplicate information in the "content" field
>of all those CommunicationEvent entities.
>
>-Al
>
>Si Chen wrote:
>
>  
>
>>Hi David,
>>
>>I thought it'd be helpful if I put everything on one email for you:
>>
>>1.  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?
>>
>>2.  How should we identify what the content type of a
>>CommunicationEvent should be?  Should we add the mimeTypeId field to CommunicationEvent?  Should we add the other contentTypeId field?
>>
>>3.  How do we associate certain communication events with the right contact mechs, so the system would know, for example, that a phone call can be made to a phone #, an email can be sent to an email address, and a letter is at a postal address?  I think it is safer to create a new associations entity, CommEventContactMechAssoc, because some comm events can happen at different contact mech types (ie, a meeting can take place over the phone or at a postal address.)
>>
>>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, Al -

So here is a summary of how I think we can solve the CommunicationEvent
requirements:
http://jira.undersunconsulting.com/browse/OFBIZ-665

Si

Si Chen wrote:

>Al,
>
>I think you are right.  It is the only way to solve problems like how to
>create different types of content, attachments, and so forth.
>
>So should we follow the Product pattern, where there were override
>fields are on the CommEvent entity itself, and then there is a
>CommEventContent entity which is like the ProductContent entity?
>
>Also, can you give me a quick review - what are the high level API
>methods required to create Contents for a CommEvent.  For example, here
>are some use cases:
>1.  Create a MIME type email, and I need to invoke the browser HTML
>editor in OFBIZ right now.
>2.  Create a mass email based on a template
>3.  Create a comm event with some attachments (ie, PDFs or pictures)
>
>Thanks!
>
>Si
>
>Al Byers wrote:
>
>  
>
>>Si,
>>
>>I am interested in David's reply, but I have some input on #2. I wonder
>>if when there is this need to start incorporating Content-related fields
>>in the CommunicationEvent, if it would not be worthwhile considering
>>tying the CommunicationEvents to a Content entity via a "contentId"
>>field. This could be done in an either/or fashion with the current
>>"content" field. The data would actually be handled by the DataResource
>>entity's mimeTypeId and characterSetId fields. I could add a new
>>dataResourceTypeId value of, "COMM_EVENT", so that the content manager
>>knows how to access the CommunicationEvent's content field, if you
>>wanted to use it.
>>
>>This is still a little muddy in my head, but some of the reasons for
>>considering this would be related to the facilities that will be
>>available in the CMS as it matures. These would include automatic search
>>indexing and the ability to treat the communication as a "blog" entry,
>>to which, qualified users could add comments, notes or instructions.
>>
>>It would also work the other way - what if you wanted to send the same
>>communication to a number of parties. By referencing a single contentId,
>>you would not have to have duplicate information in the "content" field
>>of all those CommunicationEvent entities.
>>
>>-Al
>>
>>Si Chen wrote:
>>
>>
>>
>>    
>>
>>>Hi David,
>>>
>>>I thought it'd be helpful if I put everything on one email for you:
>>>
>>>1.  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?
>>>
>>>2.  How should we identify what the content type of a
>>>CommunicationEvent should be?  Should we add the mimeTypeId field to CommunicationEvent?  Should we add the other contentTypeId field?
>>>
>>>3.  How do we associate certain communication events with the right contact mechs, so the system would know, for example, that a phone call can be made to a phone #, an email can be sent to an email address, and a letter is at a postal address?  I think it is safer to create a new associations entity, CommEventContactMechAssoc, because some comm events can happen at different contact mech types (ie, a meeting can take place over the phone or at a postal address.)
>>>
>>>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]

On Jan 9, 2006, at 6:19 PM, Si Chen wrote:

> Hi David,
>
> I thought it'd be helpful if I put everything on one email for you:
>
> 1.  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?

The pattern I have tried to use elsewhere is the "join table  
(entity)" pattern like the second one you are describing like  
OrderCommeEvent and such. This would be if we want to associate an  
OrderHeader with a CommunicationEvent. Why do it this way? Because I  
think for all of these it makes sense to say that a given  
communication could cover multiple orders, and for a given order  
there might be multiple communications.

That said, I like the idea of _not_ associating these directly with  
the CommunicationEvent, but rather going through the CustRequest. The  
point of the CustRequest is to track a specific issue or request from  
a customer (or from any other source really) and then the potential  
multiple communications, multiple quotes/orders/whatever and so on  
can be associated with that. It makes things more flexible and simple  
for potential scenarios where the reality can get more complex.

>
> 2.  How should we identify what the content type of a
> CommunicationEvent should be?  Should we add the mimeTypeId field  
> to CommunicationEvent?  Should we add the other contentTypeId field?

I like the idea of adding a simple mimeTypeId. It is specifically for  
the "content" field, so perhaps a name like contentMimeTypeId would  
be best.

BTW, for attachments to CommunicationEvents I'd like to use the  
Content and related entities. This will probably require a new entity  
to track Content attachments to the comm event. This is where I think  
the CMS stuff should relate to this. For now the "content" field with  
text is sufficient for the basic communication information in most  
cases... Note that what I am proposing is still different form the  
ProductContent pattern where fields are overridden. This allows us to  
continue using the content field, which is quite convenient in many  
ways, but more flexible with a contentMimeTypeId.

> 3.  How do we associate certain communication events with the right  
> contact mechs, so the system would know, for example, that a phone  
> call can be made to a phone #, an email can be sent to an email  
> address, and a letter is at a postal address?  I think it is safer  
> to create a new associations entity, CommEventContactMechAssoc,  
> because some comm events can happen at different contact mech types  
> (ie, a meeting can take place over the phone or at a postal address.)

I'm not sure what this question is getting at... There are  
contactMechIdFrom and contactMechIdTo fields on the  
CommunicationEvent. Is there more than this that you need?

One thing I know that is a limitation here is a Communication even  
involving more than 2 parties. For this we would need to probably  
extend the CommunicationEventRole to have a contactMechId on it as  
well. Might be a good idea to do right away...

=======================

I hope that helps with these questions and to improve the proposal in  
the Jira issue.

-David


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

[Si Chen-2]

David,

Thanks for getting back to me on these.  My comments are below:

David E. Jones wrote:

>
> On Jan 9, 2006, at 6:19 PM, Si Chen wrote:
>
>> Hi David,
>>
>> I thought it'd be helpful if I put everything on one email for you:
>>
>> 1.  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?
>
>
> The pattern I have tried to use elsewhere is the "join table  
> (entity)" pattern like the second one you are describing like  
> OrderCommeEvent and such. This would be if we want to associate an  
> OrderHeader with a CommunicationEvent. Why do it this way? Because I  
> think for all of these it makes sense to say that a given  
> communication could cover multiple orders, and for a given order  
> there might be multiple communications.
>

Agreed.

> That said, I like the idea of _not_ associating these directly with  
> the CommunicationEvent, but rather going through the CustRequest. The  
> point of the CustRequest is to track a specific issue or request from  
> a customer (or from any other source really) and then the potential  
> multiple communications, multiple quotes/orders/whatever and so on  
> can be associated with that. It makes things more flexible and simple  
> for potential scenarios where the reality can get more complex.
>
Might WorkEffort be better?  FIrst because it already has all sorts of
joins going out, and second because it is more generic than CustRequest?

>>
>> 2.  How should we identify what the content type of a
>> CommunicationEvent should be?  Should we add the mimeTypeId field  to
>> CommunicationEvent?  Should we add the other contentTypeId field?
>
>
> I like the idea of adding a simple mimeTypeId. It is specifically for  
> the "content" field, so perhaps a name like contentMimeTypeId would  
> be best.
>

OK.  I'll make the change.

> BTW, for attachments to CommunicationEvents I'd like to use the  
> Content and related entities. This will probably require a new entity  
> to track Content attachments to the comm event. This is where I think  
> the CMS stuff should relate to this. For now the "content" field with  
> text is sufficient for the basic communication information in most  
> cases... Note that what I am proposing is still different form the  
> ProductContent pattern where fields are overridden. This allows us to  
> continue using the content field, which is quite convenient in many  
> ways, but more flexible with a contentMimeTypeId.
>

So you're saying CommunicationEvent.content will *always* be the main
body of the communication event, but maybe we'll also attach some
Content items for other purposes.  So we could do that--instead of a
CommEventContentWrapper, just have CommEventContent and a method or
service to store the attachments into Content.

>> 3.  How do we associate certain communication events with the right  
>> contact mechs, so the system would know, for example, that a phone  
>> call can be made to a phone #, an email can be sent to an email  
>> address, and a letter is at a postal address?  I think it is safer  
>> to create a new associations entity, CommEventContactMechAssoc,  
>> because some comm events can happen at different contact mech types  
>> (ie, a meeting can take place over the phone or at a postal address.)
>
>
> I'm not sure what this question is getting at... There are  
> contactMechIdFrom and contactMechIdTo fields on the  
> CommunicationEvent. Is there more than this that you need?
>
> One thing I know that is a limitation here is a Communication even  
> involving more than 2 parties. For this we would need to probably  
> extend the CommunicationEventRole to have a contactMechId on it as  
> well. Might be a good idea to do right away...

Yes, this is a different issue that I thought of later as well.  I think
that's a good idea to add the contactMechIds.

The issue I was actually thinking of is just restricting the comm event
form's dropdowns, so if someone is creating an email, only EMAIL_ADDRESS
contact mechs show up, etc.  I already did this in a .bsh though.  I
don't think it requires an entity.

>
> =======================
>
> I hope that helps with these questions and to improve the proposal in  
> the Jira issue.
>
> -David
>
>------------------------------------------------------------------------
>
>
>_______________________________________________
>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]

On Jan 12, 2006, at 6:04 PM, Si Chen wrote:

>> That said, I like the idea of _not_ associating these directly with
>> the CommunicationEvent, but rather going through the CustRequest. The
>> point of the CustRequest is to track a specific issue or request from
>> a customer (or from any other source really) and then the potential
>> multiple communications, multiple quotes/orders/whatever and so on
>> can be associated with that. It makes things more flexible and simple
>> for potential scenarios where the reality can get more complex.
>>
> Might WorkEffort be better?  FIrst because it already has all sorts of
> joins going out, and second because it is more generic than  
> CustRequest?

In this case I think the meaning or definition of the entity is more  
important than existing connections. In some cases a WorkEffort might  
make sense, but what I was trying to describe was the more common  
scenario where a CommunicationEvent results in a request, and then  
the various things that would normally be related to a  
CommunicationEvent would be best related to the CustRequest.

>> BTW, for attachments to CommunicationEvents I'd like to use the
>> Content and related entities. This will probably require a new entity
>> to track Content attachments to the comm event. This is where I think
>> the CMS stuff should relate to this. For now the "content" field with
>> text is sufficient for the basic communication information in most
>> cases... Note that what I am proposing is still different form the
>> ProductContent pattern where fields are overridden. This allows us to
>> continue using the content field, which is quite convenient in many
>> ways, but more flexible with a contentMimeTypeId.
>>
> So you're saying CommunicationEvent.content will *always* be the main
> body of the communication event, but maybe we'll also attach some
> Content items for other purposes.  So we could do that--instead of a
> CommEventContentWrapper, just have CommEventContent and a method or
> service to store the attachments into Content.

Yeah, that's what I had in mind. I think in general the communication  
should be representable in some sort of text format, preferably plain  
text, but often in HTML and possibly even XML or RTF or something.

The attachments could be used in various cases, but directly apply  
when the CommunicationEvent represents an incoming or outgoing email  
or some such.

-David


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