PURPOSE
Several counter fields are performed inefficiently. They use compute methods
using length of 2many fields instead of making use of more efficient ORM
methods like read_group.
SPECIFICATIONS
No functional change, only technical performance improvements.
Purpose is to improve lead_count performance. Some people claim to gain a lot
of queries: from 90 to 30 SQL queries to read 39 partners. Hard to reproduce.
LINKS
Task ID 2196182
PR odoo/odoo#44662
Co-Authored-By: Fabien Pinckaers <fp@odoo.com>
Co-Authored-By: Victor Feyens <vfe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Reproduce the issue:
- In the CRM app, create a lead/opportunity.
- Schedule a meeting for this opportunity via
the chatter and click on create.
- Go back, the "Meeting" stat button is now at 1
- Schedule a meeting for this opportunity via
the chatter and click on edit then create.
- Go back, the "Meeting" stat button is still at 1
Cause:
When we click directly on create, the opportunity ID is in the defaults
option but when we click on edit, there is no opportunity ID.
So, this commit use the context to retrieve the concerned opportunity
and set it if it is not already set.
I splitted the solution into a private method for a better readability.
OPW-2092920
closesodoo/odoo#39964
X-original-commit: 59d154dcc1524c8f08c6a1e7aee18c722ab2e0ad
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
When creating an acitivity generating a calendar event, if
the model is not crm.lead (ex: sale.order), the default_get
will crash since no value for res_model_id is given.
This commit improves the use of mail activities by allowing their
integration with the calendar. Activity types now have a category
field that can be used to trigger some specific behavior. First
specific behavior is to have activity types of meeting category.
Creating activities of this type trigger a jump to the calendar to
schedule the meeting. Meeting activities and calender events are
linked to be able to easily navigate through the document, its activities
and its meetings.
Configuration is done using a category on activity types instead of some
hardcoded "meeting" activity to avoid issues with master data and to be
able to choose which activity type should trigger this behavior.
Linking calendar.event to documents is a good idea to allow searching and
filtering meetings. It also allow to have a link to the document from a
meeting and ease navigation.
There are currently some specific links (opportunity_id for crm.lead and
applicant_id for hr.applicant) but this commit allows some generic
document linking through a res_model_id / res_id fields pair.
Now, calendar event relative to a document (ex:
crm.lead, hr.applicant) are highlighted when
comming from there form view. The mecanism consist
in override the method of the computed field
'is_highlighted'.
