'alias_user_id' field allows to set a user when creating records through the
mail gateway. This is however quite wrong and eases spoofing. The alias owner
is not the creator of any record, nor responsible.
Current possible ways of being owner / responsible of records created through
the mailgateway
* when you send an email to an alias: if you are recognized you are already
set as creating user and logged message author;
* it is possible to use alias_defaults notably to set fields like 'user_id'
if you want to be notified / responsible of records created through this
specific alias;
Those usages are therefore sufficient, no need to have another way to spoof
users. Moreover it is hidden in technical view of aliases, no model allows
to configure it by default. Moreover since odoo/odoo@3edf181 no default
value is given to alias_user_id as it adds more (ACLs / creator) issues than
really helping setting up mail gateway flows.
Task-3453482
Prepares Task-36879 (Mail: Multi-Domain Aliases)
closesodoo/odoo#138213
Related: odoo/upgrade#5259
Related: odoo/enterprise#48692
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PR #105873 added computed indexes on the `mobile` and `phone` commits
for the benefit of `phone_mobile_search`, however it created both
indexes to work on the `phone` field as source, rather than whichever
field they were named after and partial for. As a result, the index
has no effect when searching on `mobile`.
closesodoo/odoo#135878
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS: MAIL COMPOSER IN MAILING
When using the composer with a mailing, it currently skips recipients whose
email is a multi-email due to the strict usage of 'email_normalize'.
We can improve multi-email support by effectively checking for the first
email found, using the "less strict" mode of normalize. It means more emails
are detected as valid, and therefore sent.
Due to lower support of multi-emails when sending emails, this even allows
to send multiple emails as all emails are mailed.
SPECIFICATIONS: DEFAULT RECIPIENTS
Mailings are generally done using default recipients, aka using a model method
that returns the people to mail: customers ('partner_id'), customer emails
('email_from'), specific implementation, ...
This is implementation using '_message_get_default_recipients' that returns
'partner_ids', 'email_to' and 'email_cc' that are then used in the mail
composer to generate final recipients.
In this commit we better handle the content of email fields to avoid issues
with multi-emails. For that purpose we correctly split the content of those
fields. We now have several 'email_to' for records having multi-emails instead
of a single badly-formatted 'email_to'.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@4a0d87d44f
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
Post-message hook is used in various apps to link records to a newly created
created partner. This is the case notably when used with a template as it
creates partner on the fly based on emails to always handle partners.
We now check either the complete 'email', either the normalized version of
it to avoid comparison issues with multi emails and formatted emails. As
'email_normalized' now supports multi-emails by storing the first found one
it helps finding the partner.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@e5ad9e0371
Part-of: odoo/odoo#134934
As it already normalizes returned emails some manual calls to 'email_normalize'
are not necessary. Some variable names are updated to be clearer about the
email being normalized.
Parsing contact name and email is also moved into a tool function to avoid
using a partner environment just for a tool parsing method.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@f7add44c28
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
When possible, use 'email_formatted' field on partner, instead of calling
'format_addr'. That way management of corner case input (multi emails and
double encapsulation) is managed by the computed field itself.
When 'format_addr' has to be used, ensure email part is normalized to avoid
formatting issues.
Also use tools to extract emails instead of 'email_re' regex when possible.
That way all code extracting and managing emails go through the same stack.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@1c06014531
Part-of: odoo/odoo#134934
*: base, crm, digest, mail, mass_mailing, sms, test_base_automation,
website_forum, website_sale
This commit makes "Automated Actions" more discoverable and usable by:
- Adding a menu in the kanban header config dropdown to add/edit them.
- Creating a new custom kanban view for a clear understanding of each
automated action record and its associated actions.
- Introducing new "smart" triggers that appear in the form view based on the
chosen model:
- Updated Values category:
- "Stage is set to" when a `stage_id` field exists in the model,
allowing users to select a specific stage value.
- "State is set to" when a `state` field exists in the model,
allowing users to select a specific state value.
- "Priority is set to" (`priority`) where users can select a specific priority.
- "User is set" (`user_id`, `user_ids` fields)
- "Tag is added" (`tag_ids` field) where users can select a specific tag.
- "On Archive"
- "On Unarchive"
- Timing Conditions:
- "After creation"
- "After last update"
- Deprecating previously known triggers "On Creation" (`on_create`) and "On
Update" (`on_write`) to simplify the user experience. "On Creation & Update"
(`on_create_or_write`) is retained and renamed to "On save".
- Changing the `ir.actions.server` Many2one relationship to a One2many
relationship. Automated actions can now directly contain multiple actions,
eliminating the need for an "Execute several actions" action in automation
rules.
- Introducing a widget for the new `ir.actions.server` One2many field for a
clearer understanding of multiple actions.
This commit also enhances the usability of "Server Actions" (`ir.actions`) by:
- Removing the `ir.server.object.lines` model and the associated `fields_lines`
One2Many field. The attributes of the removed model are now merged into
`ir.actions`. An action can now write to only one field, and the create action
is now a name_create action.
- Adapting the form view when creating an "Update the record" action. The value
field shown adapts itself based on the field to update; this field can be a
`reference` field for a `one2many` `update_field_id`, a `one2many` field for a
selection `update_field_id`, or a `text` field otherwise.
- Refactoring the form view to display only relevant details and other
miscellaneous improvements.
Taskid: 3085360
Part-of: odoo/odoo#114352
Co-authored-by: Florent Dardenne <dafl@odoo.com>
Co-authored-by: Julien Carion <juca@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Instead of having a count field for meetings linked to
a crm.lead, show a (start) date instead:
- If there is a next meeting, show its date + "Next Meeting"
- Otherwise, show last meeting date + "Last Meeting"
- If no meeting, show no date and display "No Meeting"
- hide button for new records
This commit removes the field "calendar_event_count" that
has no use anymore. A test using the count field is adapted.
Another is added to assert new fields behavior.
UPG PR odoo/upgrade#4935
Task-3418397
closesodoo/odoo#128366
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Cleanup alias usage and definition. Prepare code to ease future changes and
improvements. Notably
* add a 'alias_email' computed field on the mixin allowing to have the
complete alias email when set, and False in case it is inactive or linked
to an inactive alias domain;
* remove unnecessary alias_id field definition when just the help differs
from the standard definition coming from the 'mail.alias.mixin';
* use fields coming from 'inherits' instead of using alias_id and its sub-
fields; notably use 'alias_display_name' and 'alias_email' fields;
* remove useless custom code and management;
* improve alias parameters support code in configuration parameters;
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Add a '_phone_format' tool method on BaseModel. It allows to format a number
either directly, either from a field available on the model. It allows to
ease number formatting. It uses available helpers to find numbers using
'_phone_get_number_fields' and '_phone_get_country_field'. With default
generic behavior this allows to simplify most calls to phone number formatting.
Having it available at BaseModel level allows to remove some custom code,
calls to phone_validation API, ...
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Support by default 'phone' and 'mobile' fields if present on model as phone
fields to fetch when searching for a number. This allows to remove several
of unnecessary overrides always doing the same thing.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
As the "Create" button is renamed to "New" so update it and remove "top left" in
helper to enhance clarity and avoid any confusion.
Task-3420529
closesodoo/odoo#130432
X-original-commit: 7a1bcb9c74eb48877731367b3da95c1eec7db19b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If you have some leads which are nearly always won or lost, you may
end with a probability which is either 0% or 100%.
These values indicate that the lead is lost or won, therefore we must
check the limit values.
opw-3413206
closesodoo/odoo#130109
X-original-commit: 49166f3c291c44d6635d30687ec8d439de145d01
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
International formatting ease reading the value, which is handy in onchange.
This partially reverts odoo/odoo@51d571fab4 .
closesodoo/odoo#129851
X-original-commit: dab802a939c97603f70c504e98ecc92b0ac552f9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
This commit implements the `mail.tracking.duration.mixin` with the
`statusbar_duration` widget for `crm.lead` and `project.task`.
The goal is to compute and display how long a record has spent in each stage in
the statusbar of their form view.
Task-3032773
Part-of: odoo/odoo#108554
Most number formatting is done using E164 standard, see notably
'phone_get_sanitized_number' method in mail.thread.phone.
Some calls are still done using INTERNATIONAL format. Notably on 'partner'
and 'lead' model, an onchange is implemented that formats numbers according
to INTL format. However this leads to inconsistent computation where sanitize
is done using E164, and format using INTL. This makes some computation and
comparisons harders without much real added value.
In this commit we choose to make the onchange on those models use the same
E164 format as the sanitized one. This eases comparisons and usage of phone
numbers through Odoo.
Task-3342820
X-original-commit: 51d571fab4871fd62ce154b6fc1ed573407c7f86
Part-of: odoo/odoo#128118
The method _assign_and_convert_leads() gets called when the CRM: Assign Leads cron is called.
The values in the list `weights` gets caluclated in a way that memebers with a lower
`lead_month`count` value gets a higher weight when randomizing assignement of a new lead. Assuming that the
max assignment per member is consistent (or default = 30).
Assume that each sale member belonging to any team has around 500 leads assigned to them the previous
month(`lead_month_count`) and `work_days` is set to `0.2`. The return value of the method
`_get_assignement_quota()` in this case would be 0 for every member, which causes the list `weights`
to get populated with just zeros. This raises a `ValueError: Total of weights must be greater than zero`.
Fix:
Make sure the minimum weight for each member is at least 1 and not 0.
opw-3171085
closesodoo/odoo#121908
X-original-commit: 15e2a1ebe2e64b752fb1c1d6bc422beb7d548b78
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Uninstallation does not cope well with `setup_models` being performed
unconditionally as those will dramatically alter registry states, and
resurrect computes which the uninstallation has disabled: rather than
try to update registry models in-place (which is rather fraught) the
uninstallation deletes the columns, tables, and `ir.*` reflection
records and only after all of that is done does it reset the registry.
This means while it does fix up the registry caches (`field_depends`
and `field_triggers`) as it goes, resetting those may cause the
recomputation of fields whose columns have been deleted, possibly
based on dependencies whose columns have also been deleted.
As such these kinds of manipulations should either be performed in
`@ondelete` methods which don't get executed during uninstallation, or
they should be gated behind an uninstallation check.
In crm the latter is necessary, as `ondelete` runs before `unlink`
actually executes, and the registry reset would run too early (and
unnecessarily).
In base, only the latter is possible as we're not in `unlink` itself,
instead `IrModelFields._prepare_update` is called *during*
uninstallation and its trailing `setup_models` causes the issue.
X-original-commit: 357b9f2c9fd44e14e5b7c9d3c17f1794691986f3
Part-of: odoo/odoo#121522
This cancels the changes added to f91782279a
for minor version 16.3 as the server action is completely removed
instead of being fixed in this.
The action is not removed in the upgrade as it is still technically
working. Though it should be considered deprecated.
------------------------------------
We remove the action that was used to conditionally call a window action
The action was not called consistently and added confusing indirection.
To maintain the current behaviour of only suggesting adding a loss
reason for opportunities.
We make the reason fields toggleable in the wizard, and hide them by
default for leads.
This leaves the user with the option to add a reason anyway, and serves
as a confirmation wizard if they don't want to.
-------------------
task-3272955
closesodoo/odoo#118494
Related: odoo/upgrade#4640
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Prior to this we used the context active_ids directly to determine
which leads to mark as lost in the lost reason wizard.
We now use a m2m field to store that value to make the behavior more
obvious and predictable, and to ease debugging.
task-3272955
Part-of: odoo/odoo#118494
Draw attention to the monthly assigned lead count when
it is exceeding the limit by changing the text color
to orange.
Task-3204763
Part-of: odoo/odoo#115326
Enforce strict types for returned values for
* create
* write
* unlink
* default_get
to make those methods more consistent and reliable.
Also make sure they can be called with empty self/values,
i.e. that they follow the same behavior as the base methods
defined in the main orm Model.
closesodoo/odoo#116809
Related: odoo/enterprise#38880
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Prior to this notification actions are shown as such:
MODEL RECORD_NAME won | lost | settings
After they will be shown as such:
MODEL won lost settings RECORD_NAME
with the action links colored to match the company color.
The aim is to streamline the layout of e-mails and make actions
clearer.
task-3067315
closesodoo/odoo#106307
Related: odoo/enterprise#34284
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: account, crm, hr_recruitement, im_livechat, point_of_sale,
project, sale_management, website_sale
Purpose
=======
Now, the KPI are computed based on their `company_id` and not based
on the current company. If no company is set on the digest, we compute
it based on the current company.
The KPIs are computed based on their company. Most of the time, they
will all belong to the same company so we can improve the performance
by computing them in batch.
Task-2827996
See odoo/enterprise/pull/27658
Part-of: odoo/odoo#91945
Prior to this all of the context of the action called in the list
action was overriden. We now combine the action context with the
environment context.
This allows keeping the context from the XML action that defines the modal sizing.
task-3235932
closesodoo/odoo#116287
Related: odoo/upgrade#4493
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
This commit contains mainly code cleaning, docstrings and a small split
for notification tool methods. In this commit we
* make some notification groups variable explicit;
* move the filler of groups into its own submethod to ease being called
from other code (to be used soon);
* fix some strange overrides or code manipulation;
* propagate some additional parameters to ease future commits that will
improve rendering of groups-based notification emails;
* cleanup, fixup and improve docstrings;
This does not change anything from functional point of view, just preparing
further work.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
RATIONALE
Duplicates computation on leads is slow when having a lot of leads. We can
simplify the heuristic to keep only relevant terms and use tailored fields
to find duplicates based on email and phone, to speedup the computation while
loosing few duplicates or avoiding false duplicates.
SPECIFICATIONS
We remove
* an ilike on email_normalized (slow and exact matches are what really
matters);
* an ilike based on partner_name and contact_name (as lead is a contact
oriented record, better optimize email and phone / mobile than names that
are weak criterions);
* an ilike on phone_mobile_search, which was searching on both fields
phone and mobile;
Criterions are now
* email domain exact match;
* phone_sanitized exact match;
* same commercial entity;
Main change is that only phone_sanitized is used for exact match. Partial
matching based on phone and mobile number is lost. That should not be an
issue as real duplicates should come with a complete phone or mobile number
and not partial numbers. First found in phone / mobile populates the phone
sanitized field, meaning if we have two different numbers, only one is used
for duplicate finding. This is considered acceptable.
Other main change is the removal of partner name / contact name search. Those
are weak criterions and did not return any explicit result when used internally.
Task-3142659 (Crm: Fix duplicate leads computation performances)
Part-of: odoo/odoo#112535
RATIONALE
Duplicates computation on leads is slow when having a lot of leads. We can
simplify the heuristic to keep only relevant terms and use tailored fields
to find duplicates based on email and phone, to speedup the computation while
loosing few duplicates or avoiding false duplicates.
SPECIFICATIONS
Index on "phone_sanitized" field of <crm.lead> is added as btree_not_null as
it is mainly used to search for direct matches. Partial searches are not the
main usage of this field.
Task-3142659 (Crm: Fix duplicate leads computation performances)
Part-of: odoo/odoo#112535
When logging a meeting linked to a lead we now add a link to the
record. The link takes the place of the subject as it's the same
displayed value.
task-2984657
closesodoo/odoo#106546
Related: odoo/enterprise#32945
Related: odoo/upgrade#3974
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This fulfills the goal of searching and fetching fields in a single SQL
query. We introduce the new method search_fetch() for that purpose.
Also introduce method fetch() to fetch some fields for a recordset if
they are not in cache yet.
The call graph is as follows:
search() calls search_fetch()
search_read() calls search_fetch() and _read_format()
read() calls fetch() and _read_format()
search_count() calls _search()
search_fetch() calls _search() and _fetch_query()
fetch() calls _search() and _fetch_query()
The methods _search() and _fetch_query() are usually the ones to
override to implement business-specific logic. The method _search()
returns a Query object to retrieve the records that satisfy the given
domain and are accessible for reading. The method _fetch_query() uses a
Query object to retrieve fields from the database and store them in
cache.
Also use search_fetch() to save one query in search_read() and the
reading of one2many fields.
Part-of: odoo/odoo#112126
The parameter in search() is redundant with method search_count(), and
was making the calls less readable.
The method _search() is aimed at always returning a Query object. The
method can therefore never return an integer, hence the removal of the
parameter. This does not actually remove any functionality from the
method; counting result is simply given by using it differently.
Part-of: odoo/odoo#112126
Define information taken from the lead when a partner is automatically
created from it. It avoids the user to enter the information twice and
automated partner creation now correctly takes information when possible.
Task-3024050
Part-of: odoo/odoo#105111
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
*: base, account, crm, hr, hr_attendance, test_access_rights
The various public methods of the ORM can be override in other models,
those overrides sometime don't implement the exact same signature as the
original method in the ORM. In this work we sanitize all the overrides
to ensure a better compatibility. The background objective is to make it
possible to call any public method using kwarg: `search(domain=[...])`.
* `search`, the first parameter was renamed from `args` to `domain` in
0e9adf7 but the overrides were not updated.
* `invalidate_models` and `invalidate_recordset`, a new `flush=True`
parameter was introduced in 9c3b9a4 but the overrides were not
updated.
* `update`, there is a clash between the `update` method responsible for
writing on a record and `update` in bus responsible to update the user
presence. The bus method has been renamed so it doesn't clash with the
ORM.
This sanitization comes with a new linter that verifies that all
overrides of BaseModel public methods share a compatible signature. The
linter has been disabled for `create`, `write` and `default_get` as too
many overrides don't respect the signature of BaseModel.
closesodoo/odoo#106999
Related: odoo/enterprise#34991
Signed-off-by: Julien Castiaux <juc@odoo.com>
This index allows to improve performances of learch searching based on phone
and mobile fields. We currently use those fields are phone_sanitized is
based on both fields, which could lead to information loss and/not not
accurate results, notably when used to find duplicates.
Task-3007714
closesodoo/odoo#105873
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Accelerate duplicate lead detection by adding indexes on field involved in the
search.
In this commit we add trigram indexes on email_normalized, partner_name and
contact_name that are used a lot for searching and finding leads.
Task-3007714
Part-of: odoo/odoo#105873
* = crm, mail, survey, test_event_full, website_event
To increase readability and performance, use f-strings where appropriate
(multiple concatenation +- formatting).
Note: Also removing unnecessary string concatenation with `%` for `(i)like`
in domains definitions.
Task-2977548
See odoo/enterprise#31156closesodoo/odoo#99811
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Some cases require usage of Markup in order to correctly display HTML content
and avoid escaped or invalid statements.
Fix: in hr_recruitment, support default_job_id from context, easing display
of job's alias in empty list helper.
Task-3074357
closesodoo/odoo#106061
Related: odoo/enterprise#34139
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to cleanup code: stop using help parameter name (use help_message as
help is a keyword), try to call super(), ...
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#105992
Purpose:
In the Forecast view of the CRM module, when recurring revenues are activated,
they are not shown in the progress bar of each stage of the kanban view. Only
the prorated expected revenue (non-recurring) are shown. In the regular
kanban view, they are shown.
To display them, we extended the CrmKanban view, which already possesses this
behavior, since behaviors relevant to the CrmKanban view are also relevant
to the ForecastKanban view.
As for the forecast kanban cards, when recurring revenues are activated,
they show "regular" recurring revenues instead of "prorated" recurring
revenues. Expected revenues are prorated. This is misleading for users.
The goal is to show prorated recurring revenues instead of just
recurring revenues.
Task-2994146
Task-3006404
closesodoo/odoo#102037
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The same override of `_get_view` was done in `res.partner` and `crm.lead`
in order to call `_view_get_address`, to change the address format
of the partner and lead form.
The definition of `_view_get_address` was already shared between these
two models through the `format.address.mixin` mixin.
So, why not share the override of `_get_view` also in this mixin,
so only one override needs to be written, instead of two.
In addition to merge the code of the `_get_view` override
in `format.address.mixin`, also set the `_get_view_cache_key`,
so the partner and lead form are correctly cached by company,
in case multiple companies in a same db use different address views.
Before this revision, this wasn't the case for `crm.lead`,
which therefore leaded to a bug when two companies where
using different address view, and one company accessed the lead
form before the other, therefore caching its own view version
in the cache, re-used later by the second company when fetching
its own lead form.
This revision takes the opportunity to add a unit test for crm.lead,
to assert the expected form according to the company address.
There was already a test for res.partner, but not for crm.lead.
To avoid copy/pasting the unit for both models,
a common test class is created, re-used to test both res.partner
and crm.lead.
closesodoo/odoo#103438
X-original-commit: 7e4a8b77024af663c5555c6d56557e2c6136b24b
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The code removed by this revision was initally introduced in
odoo/odoo@126ba0a9a8
The `_get_view` override introduced relied
on the context key `opportunity_id`,
which was set in the crm.phonecall form view with
```xml
<field name="opportunity_id" on_change="on_change_opportunity(opportunity_id)" context="{'opportunity_id': opportunity_id}"/>
```
as you can see in the above mentioned revision.
This above node was removed 7 years ago in revision
https://github.com/odoo/odoo/commit/ff2b14d4c3c5aaa62418b527585d0a19e98a23de#diff-892062d6151c1e1c1cb5f6c09035df1d5ae6d5a71f7558aacfdc8cf62627bf5fL138
Therefore making pointless the code about it in the `_get_view`
override.
In addition to this clue to make sure the override is pointless,
checking the code, we can see it relies on `get_formview_action`
to set a different view according to the result of `get_formview_action`.
Since revision
https://github.com/odoo/odoo/commit/e28d3aa4d3851d72deba08c236072d002f83216a#diff-595d3dbbabdc4f766a380a320c1c1a43b143385bc7487c7275e80f76a9fbabc2L1224
the override of `get_formview_id` is removed,
therefore making `get_formview_action` of `crm.lead` completely default
(as there is no override of `get_formview_action` either in crm.lead,
nor any dependent method)
We can therefore assume this code was useless,
at least in standard odoo,
and can therefore be removed.
X-original-commit: 82c2f4b13034c16ca5546afd777150ecb4d8ad9b
Part-of: odoo/odoo#103438
Martin Trigaux