# Party Communication Event

**URL:** https://discuss.tryton.org/t/party-communication-event/5165
**Category:** Feature
**Created:** [April 6, 2022, 9:08am UTC](https://discuss.tryton.org/t/party-communication-event/5165 "2022-04-06T09:08:13Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 6, 2022, 9:08am UTC](https://discuss.tryton.org/t/party-communication-event/5165/1 "2022-04-06T09:08:14Z")

</div>

## Rational

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.

## Proposal

In a new module `party_communication`:

We add a model `party.communication.event` with:

- `company`
- `parties` : `Many2Many` to `party.party` 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 `party.communication.case` (optional) limited to `party in parties`
- `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 `party.communication.work.effort`
- `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 `party.communication.case` is defined with:

- `name`: `Char`
- `description`: `Text`
- `party`: `Many2One` to `party.party`
- `reference`: `Reference`
- `start` and `end`: `DateTime`
- `events`: `One2Many` to `party.communication.event`
- `works`: `One2Many` function to linked `party.communication.work.effort`
- `status`: `Many2One` to `party.communication.case.status` (similar to `project.work.status`).

Relate actions are created for each available reference.

The follow up are stored in `party.communication.work.effort` with:

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

\_The `work.effort` model comes from [Add module to allow services to be invoiced when they are done (#9999) · Issues · Tryton / Tryton · GitLab](https://bugs.tryton.org/issue9999_)

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

## Implementation

> **[Add party communication module (#11911) · Issues · Tryton / Tryton · GitLab](https://foss.heptapod.net/tryton/tryton/-/issues/11911)**
>
> Following https://discuss.tryton.org/t/party-communication-event/5165

---

<div class="post-metadata">

### Author: ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [April 6, 2022, 9:18am UTC](https://discuss.tryton.org/t/party-communication-event/5165/2 "2022-04-06T09:18:44Z")

</div>

> [@ced](#):
>
> `case`: `Many2One` to `party.communication.case` (optional) limited to `party in parties`

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.

> [@ced](#):
>
> `effort`: `Reference` [`work.effort`, `project.work`]

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.

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 6, 2022, 9:26am UTC](https://discuss.tryton.org/t/party-communication-event/5165/3 "2022-04-06T09:26:54Z")

</div>

> [@pokoli](#):
>
> 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.

Then I would link the case to the opportunity.

> [@pokoli](#):
>
> 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.

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.

---

<div class="post-metadata">

### Author: ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [April 6, 2022, 9:45am UTC](https://discuss.tryton.org/t/party-communication-event/5165/4 "2022-04-06T09:45:17Z")

</div>

> [@ced](#):
>
> Then I would link the case to the opportunity.

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.

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 6, 2022, 10:24am UTC](https://discuss.tryton.org/t/party-communication-event/5165/5 "2022-04-06T10:24:07Z")

</div>

> [@pokoli](#):
>
> But for the User Point of view it will be complex to create a case

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

> [@pokoli](#):
>
> I will prefer if the user has a One2Many on the opportunity to track all the communication events of such opportunity.

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

> [@pokoli](#):
>
> 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.

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

---

<div class="post-metadata">

### Author: ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [April 6, 2022, 10:49am UTC](https://discuss.tryton.org/t/party-communication-event/5165/6 "2022-04-06T10:49:20Z")

</div>

> [@ced](#):
>
> > [@pokoli](#):
> >
> > But for the User Point of view it will be complex to create a case
> 
> I do not think the usability must drive the data design

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

> [@ced](#):
>
> One2Many will neither contain the follow up communication because they are just linked to the original communication.

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

> [@ced](#):
>
> A single opportunity can have multiple cases.

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?

---

<div class="post-metadata">

### Author: ![timitos](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/timitos/32/323_2.png) [@timitos](https://discuss.tryton.org/u/timitos)
#### Post date: [April 6, 2022, 11:17am UTC](https://discuss.tryton.org/t/party-communication-event/5165/7 "2022-04-06T11:17:22Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 6, 2022, 11:30am UTC](https://discuss.tryton.org/t/party-communication-event/5165/8 "2022-04-06T11:30:02Z")

</div>

> [@pokoli](#):
>
> Why not? The follow up comunication should be linked to the same case so they will be all included on the same opportunity.

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.

> [@pokoli](#):
>
> That sound strange for me all the comunication is related to the opportunity (so a single case).

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

> [@timitos](#):
>
> link the communication event directly to the opportunity without having an unneeded extra model

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

---

<div class="post-metadata">

### Author: ![timitos](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/timitos/32/323_2.png) [@timitos](https://discuss.tryton.org/u/timitos)
#### Post date: [April 6, 2022, 11:36am UTC](https://discuss.tryton.org/t/party-communication-event/5165/9 "2022-04-06T11:36:01Z")

</div>

> [@ced](#):
>
> 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?

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 6, 2022, 11:37am UTC](https://discuss.tryton.org/t/party-communication-event/5165/10 "2022-04-06T11:37:49Z")

</div>

> [@timitos](#):
>
> It should be no problem to do a proper migration if the case model is added later.

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

> [@timitos](#):
>
> 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?

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

---

<div class="post-metadata">

### Author: ![timitos](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/timitos/32/323_2.png) [@timitos](https://discuss.tryton.org/u/timitos)
#### Post date: [April 6, 2022, 11:43am UTC](https://discuss.tryton.org/t/party-communication-event/5165/11 "2022-04-06T11:43:52Z")

</div>

> [@ced](#):
>
> I’m not talking about a future migration but an extension.

I do not see why this should not be possible.

> [@ced](#):
>
> Mainly it is to group communication events under a common topic.

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.

---

<div class="post-metadata">

### Author: ![albert](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/albert/32/21_2.png) [@albert](https://discuss.tryton.org/u/albert)
#### Post date: [April 6, 2022, 1:02pm UTC](https://discuss.tryton.org/t/party-communication-event/5165/12 "2022-04-06T13:02:22Z")

</div>

> [@timitos](#):
>
> 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](https://github.com/nan-tic/trytond-activity) module which basically implements the same Event concept and we link it with [opportunities](https://github.com/NaN-tic/trytond-sale_opportunity_activity) or [projects](https://github.com/NaN-tic/trytond-project_activity/) 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).

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 6, 2022, 3:16pm UTC](https://discuss.tryton.org/t/party-communication-event/5165/13 "2022-04-06T15:16:33Z")

</div>

From [The Data Model Resource Book](https://www.oreilly.com/library/view/the-data-model/9780471380238/):

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

---

<div class="post-metadata">

### Author: ![timitos](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/timitos/32/323_2.png) [@timitos](https://discuss.tryton.org/u/timitos)
#### Post date: [April 6, 2022, 3:38pm UTC](https://discuss.tryton.org/t/party-communication-event/5165/14 "2022-04-06T15:38:03Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 6, 2022, 3:42pm UTC](https://discuss.tryton.org/t/party-communication-event/5165/15 "2022-04-06T15:42:39Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![timitos](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/timitos/32/323_2.png) [@timitos](https://discuss.tryton.org/u/timitos)
#### Post date: [April 6, 2022, 3:50pm UTC](https://discuss.tryton.org/t/party-communication-event/5165/16 "2022-04-06T15:50:50Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 6, 2022, 3:54pm UTC](https://discuss.tryton.org/t/party-communication-event/5165/17 "2022-04-06T15:54:33Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![timitos](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/timitos/32/323_2.png) [@timitos](https://discuss.tryton.org/u/timitos)
#### Post date: [April 6, 2022, 3:58pm UTC](https://discuss.tryton.org/t/party-communication-event/5165/18 "2022-04-06T15:58:44Z")

</div>

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?

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 6, 2022, 4:07pm UTC](https://discuss.tryton.org/t/party-communication-event/5165/19 "2022-04-06T16:07:17Z")

</div>

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

---

<div class="post-metadata">

### Author: ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [April 7, 2022, 7:28am UTC](https://discuss.tryton.org/t/party-communication-event/5165/20 "2022-04-07T07:28:33Z")

</div>

> [@ced](#):
>
> 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.

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?

[Next page](https://discuss.tryton.org/t/party-communication-event/5165.md?page=2)
