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?
Tree structure is annoying here. Indeed this is the case to group communication events.
So I think the best will be to have a wizard to schedule a follow up communication event that will create the case if needed and then create an event at the planned date.
I think a relate from the referenced document will be better than a One2Many because cases can be a keep growing list. So from this list the user can create a new case or complete one and in the form view of the case he can create a communication event.
Sounds interesting but I do not fully understand from where the wizard will be executed. For me it should be possible to schedule a communication from a event but also from other models (like sale.opportunity and sale.complaint.
Won’t be better to just create the relate to the comunication event? So from the form view you can create a new case if needed but select the current one if already exist. Altought it will probably better to just set the existing one as default if only one exists (or if others are already closed due to and end date).
This is execute from a current communication event as follow up.
I do not think it happens from no where that a users without having a communication with external needs to schedule a communication.
Any way, in such case he has to open the cases (create a new one or use an existing) and create a communication event.
It does not work as it is the case that does the link.
If I understand this correctly you expect the user that is working on an opportunity to create a case only to create an event later. That is creating manually two models just to fill in an event.
For me it is already hard enough to convince users to properly use opportunities and events. Try making them create intermediate models that they will find no usage for, and you’ll have a hard time trying to put such a system in real use.
I guess it is possible to add a Function Reference field on the communication event with a searcher and a setter so it is possible to have a direct relate.
The setter will have to create the case automatically and it should do nothing it there is already a case (the function field should be readonly).
That’s my real concern here. If the user needs to do a lot of steps for just recording a done communication or mark one call as already done we will miss most of the usage of this feature.
I just checked Suite CRM demo and they allow to record any communication (call, meeting, emails) directly from any model (opportunity, case, etc). So the user just need to enter the communication detail and it’s status.
Also I’ve seen that there is a responsible field for all the comunications which they use to show a “My events” list. I think it will be great to have a similar view on Tryton.
That makes sense. Indeed we should use such Reference field for the relates on other Tryton models.
As long as the case isn’t required, I see no problem. A references field with a many2many can be added to the communication from external module.
But we have similar experience with this kind of not necessary task. Users often see no direct benefit to collect communications, so the requirements for them should be minimal. We thought about making the client able to show communication events on related models, like notes and attachments or like emails. Adding a new communication on a model would auto fill all related parties and a reference to the model.
Also we should think about a way to integrate Tryton emails into the communication model, as these are already communications of type email.
Anyway email, communications and notes are all very similar and should be unified IMHO.