Party Communication Event


For many business, it is important to track whom and when contact or communication was made between parties. Often it is needed to know for a customer (or a supplier) who called them when and for which purpose. It is also needed to plan them in advance.
Sometime it may be useful to group a set of communications under a single case.
And finally communication often requires a follow up as one or multiple actions (work effort) to be taken.


In a new module party_communication:

We add a model party.communication.event with:

  • company
  • parties : Many2Many to with the involved parties in the communication (include the employee automatically).
  • contacts: Many2Many to party.contact_mechanism limited to parties and the type
  • case: Many2One to (optional) limited to party in parties and not available when parent is filled
  • reference: Function that display the value from the case with a setter and searcher
  • start and end : DateTime
  • purpose: Many2One to party.communication.event.purpose
  • type: Selection [phone, email, etc] (same as for contact mechanism).
  • note: Text
  • follow up: One2Many to
  • state: Selection [scheduled, in progress, completed]

A wizard eases the creation of follow up communication by creating an empty case if needed and copy with new dates the current event.

The party.communication.event.purpose model store the configuration of purpose with:

  • name: Char

The is defined with:

  • name: Char
  • party: Many2One to
  • reference: Reference
  • start and end: DateTime
  • events: One2Many to party.communication.event
  • works: One2Many function to linked
  • status: Many2One to (similar to

Relate actions are created for each available reference.

The follow up are stored in with:

  • event: Many2One to party.communication.event
  • name: Char
  • effort: Reference [work.effort,]
  • state: Selection [scheduled, in progress, completed]

The work.effort model comes from Issue 9999: Add module to allow services to be invoiced when they are done - Tryton issue tracker

We add a relate from party to communication events and cases.


I’m wondering if we should make the case an reference field.
It is quite common to relate all the comunications related to a sale opportunity into a single case, so we should be able to relate to at least sale.opportunity here.

Sometimes the followup of a communication event is another communication event. So I think we should allow to have party.communication.event also as follup of another event.

Then I would link the case to the opportunity.

First the work effort could be make a communication (even if it is little bit special).
But indeed we could add a events list on the event to schedule new communication.

But for the User Point of view it will be complex to create a case and manage all the comunication from the related case as the user will have the information split into two screens (one for communication another for the opportunity). I will prefer if the user has a One2Many on the opportunity to track all the communication events of such opportunity.

I’m wondering if it will be a good idea to follow the same design as we do on timesheet lines and projects. The idea is to have a checkbox on opportunity to enable comunication and when checked the system creates automatically the case for the opportunity.

Then the user will be able to see all the events of the case directly from a One2Many field in the opportunity.

The same should be applicable for other models like: Sale Complaint So probably we should make the module have a list of extra depends to have more generic comunication methods activated by default.

I do not think the usability must drive the data design.

But such One2Many will neither contain the follow up communication because they are just linked to the original communication.

I do not think so. A single opportunity can have multiple cases.

Of course not, but we should take in account the usability to design the user interface and that’s what I amb talking about.

Why not? The follow up comunication should be linked to the same case so they will be all included on the same opportunity.

That sound strange for me all the comunication is related to the opportunity (so a single case).
Could you provide an example of a single opportunity with multiple cases?

I think that the case model may not be needed in this module. This way @pokoli could link the communication event directly to the opportunity without having an unneeded extra model. For me the module would be more generic this way.

For data integrity, it is not possible to guarantee such constraint. So the link of follow up communication to the case is done though the parent.

The communications may have different topics about the opportunity (or what ever).

But it will make it impossible to add the case model later.

I do not agree. It should be no problem to do a proper migration if the case model is added later. Maybe we do not understand the “case” model on the business level. Can you please give some examples for a “case” and why it is needed?

I’m not talking about a future migration but an extension.

Mainly it is to group communication events under a common topic.

I do not see why this should not be possible.

But if you link the event to the opportunity it is already grouped by the reference to the opportunity.
Do you have any use case for an additional grouping? For now i did not find any argument to create a grouping model for events as there are a lot of models in tryton already that would be a good fit for grouping events like “sale.complaint” for example.

I agree with Korbinian.

We’ve been using the activity module which basically implements the same Event concept and we link it with opportunities or projects using a Resource (fields.Reference) field.

We never felt the need of a “case” model (in fact we got were happy to get rid of it as it existed in OpenERP).

From The Data Model Resource Book:

A CASE may be set up for a series of
Related COMMUNICATION EVENTs regarding a particular issue. Each CASE
may have several CASE ROLEs that identify who is responsible for the CASE,
who checks the quality of service within the CASE, who is the customer for the
CASE, and so on.

I think all the things that should be set on the case are already defined by our other models like the sale opportunity or the sale complaint. As we have all of this in one database i think we should not add a new model to define that but just do it on the existing ones like we already do.

I think this is a oversimplified vision.
Using other process document as grouping tool is a poor and limited design. It prevents to collect data about a specific case like report duration, the party involved, status etc.

We are working with such a design in a lot of projects and like @albert we never missed such a case model. And in fact like @albert i had such a model in the first run but we removed it before setting our module into production. And like @albert i had copied such model from TinyERP at that time.

I think that many CMS solutions do have such a case model because they are missing the possiblity to link the conversation directly to the object that it is related to. But we can do that. I would really prefer to have the reference field on the event like @pokoli proposed.

I see no counter proposal about how to group of communication.
For me the case will stay as long as there is no other counter proposal with the same feature.
And those who does not want to use it, will just not use it.

So why not leave it out of the base module? If somebody will need it he can easily add it later? That was my first proposal?

Because it can not be added by extension if you put the reference to the communication.

For me the Case model makes sense but I think we need to find an easy way for users to create cases from other models (like sale.opportunity and sale.complaint) and relate comunication events to the model using the case reference. Maybe just adding a One2Many to the models with a domain to the reference field of the case will work.

This will force the user to create a case when None exists and then let them create more if required but use the existing one if only one is found.

Does it make sense?