Instead of triggering one has_group by user (one sql query/user if not already ormcached),
and potentially filling the `has_group` cache with new users data (we don't know if and when this data
will be used anyway), compute this field from the groups information already in cache.
X-original-commit: d771d7e9c8503543d29fdbf2ab961c2a32cc3bac
The main classes of partners and users support batch creation, but
the majority of their overrides doesn't support creation in batch.
Adapting those overrides to support records creation in batch shows
great performance gains:
* On `res_partner` : 2 to 3 times faster
* On `res_users`, with the inherited `res_partner` created in batch:
up to 10 times faster.
Tests done with 500 to 4k records:
* `res_partner` with only a name provided
* `res_users` with a name and login
X-original-commit: 9c3c5f161580039c1fe50f68acac808c18817997
We also have to update code calling directly the rendering itself. Indeed
some code bits does some rendering directly on jinja-enabled input and not
through templates. Those calls have to be updated accordingly.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
PURPOSE
Clean and rename code about language management and template rendering in mail
template model.
SPECIFICATIONS
Clean method naming and try to make code easier to understand and call. Also
add and/or clean docstrings of rendering methods.
Notably
* ``_classify_per_lang``: for each lang-contextualized template, give the list
of record ids;
* ``_render_template``: now working only on a valid list of IDs instead of
allowing both int / list and having a return type depending on the input
type. It allows to simplify code and delegate some processing to callers;
Introduce new API method
* ``_render_lang``: for each record id return the lang matching it;
* ``_render_field``: render a field of mail.template, on given set of record
ids. Usage: template._render_field('body_html', records.ids). Language
computation is available for this method;
Remove the "multi mode" support of rendering that either returned a rendered
value, either a dict based on given ids. Now all methods always work in batch
and caller have to fetch the correct result if necessary.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
PURPOSE
Ease edition of digest tips by adding a name.
SPECIFICATIONS
Add a name on digest tips. Even if technical and not send to customers it
allows to see them at a glance in list view without having to guess their
content.
LINKS
Task ID 2214325
Com PR odoo/odoo#47416
Related: odoo/upgrade#933
Related: odoo/enterprise#9167
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Allow to edit and improve digest tips by adding views.
SPECIFICATIONS
Add views for digest tips. Locate those views in technical menu, in email
section, below Digest Emails.
LINKS
Task ID 2214325
Com PR odoo/odoo#47416
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Before this commit, the computation of kpi for last week, last 30 days and
previous period comparison was wrong due to cache. Indeed as first value
was in cache, other values were taken directly from cache itself instead
of recomputing each value based on start_date and end_date of the computation
timeframe.
As digest fields are computed fields used a bit off-side, let us manually
invalidate the cache before computing a kpi so that it correctly computes
the timeframe values.
Task ID 1883428
closes odoo/odoo#40861
Closes: #40834
X-original-commit: 2966ee59cabc2bbae91e4ac4701fc393bc3770ae
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to lessen size of technical "Email" menu and move some
discuss menu entries in their own menu. It will be the new first menu
entry in technical, before Emails that is more technical.
Some menu items are moved in this new menu, notably followers, messages
or mail blacklist.
Emails menu is also reordered, to have notably all channels related
entries together, ...
Task 2118599
PR #39460
The `forcecreate=0` is required because the ICP will be deleted when set
to `False` (which is quite frequent for a boolean).
closesodoo/odoo#37103
X-original-commit: 255a12931d2a22dfadb1455a5dfc0a5e2f37b730
Signed-off-by: Christophe Simonis <chs@odoo.com>
Sébastien Mottet (oms)