Odoo/addons/gamification/data/goal_base.xml, branch 14.0 The current checkout of upstream Odoo [IMP] gamification,gamification_sale_crm: compute goals using batch mode 2020-12-11T16:09:35+00:00 Benoit Socias bso@odoo.com 2020-12-08T14:20:43+00:00 0f9411d10753aa96103ce77702dbdc0516e9969a Trying to improve the resources used by the challenge update cron operation. Before this commit some count-based goals and all sum-based goals were computed with one select count or sum per user. After this commit each count or sum based goal is computed in a single select for all users. The goal form now also allows to enable batch mode for sum computations. Other changes include: - adding an index on the challenge_id of goals after verifying the positive impact of such an index on high volumes on a staging server - introducing additional intermediary commits to allow massive crons to catch up over several attempts. task-internal closes odoo/odoo#63030 Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com> 
Trying to improve the resources used by the challenge update cron
operation.

Before this commit some count-based goals and all sum-based goals were
computed with one select count or sum per user.

After this commit each count or sum based goal is computed in a single select
for all users. The goal form now also allows to enable batch mode for
sum computations. Other changes include:
- adding an index on the challenge_id of goals after verifying the
positive impact of such an index on high volumes on a staging server
- introducing additional intermediary commits to allow massive crons to
catch up over several attempts.

task-internal

closes odoo/odoo#63030

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
[REF] mail, various: remove user_signature field from mail.template 2020-02-11T14:01:13+00:00 mcm-odoo mcm@odoo.com 2019-10-24T06:08:59+00:00 de1743ab126309d6c2b6a189305ce6a3e1e1fd18 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> 
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>
[IMP] *: use `ref=` instead of `eval="ref('` in xml field tags. 2020-02-11T13:07:06+00:00 Victor Feyens vfe@odoo.com 2020-02-07T13:42:17+00:00 d4e0fe018d05fd0dc3e9ab77977d6e97440c73c0 * Code cleanup * Avoid a safe evaluation of the field value when loading those records. closes odoo/odoo#44883 Related: odoo/enterprise#8283 Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com> 
* Code cleanup
* Avoid a safe evaluation of the field value when loading those records.

closes odoo/odoo#44883

Related: odoo/enterprise#8283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
[IMP] (website_)mail: improve routes and management of mail followers 2020-01-21T16:40:06+00:00 Rémy Voet (ryv) ryv@odoo.com 2020-01-08T10:09:20+00:00 15c934a1abfc72c965a6b46618b7b2ae6fad49cc Purpose of this commit is to improve model of followers, notably management code and its use in routes. Indeed it is quite an old model and code had to be cleaned a bit to improve code readability and maintenance. In this commit we * remove unnecessary code examples in gamification about followers: using that model as example of code for goals is probably not a good idea as it is technical; * rewrite routes called by JS are simplified to better match JS implementation; * introduce computed fields to fetch related partner or channel name, email (partner only) and active status; LINKS Task 1933771 Task 2078313 closes odoo/odoo#39808 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> Co-authored-by: Remy Voet <ryv@odoo.com> Co-authored-by: jgi-odoo <jgi@odoo.com> Co-authored-by: Xavier-Do <xdo@odoo.com> 
Purpose of this commit is to improve model of followers, notably management
code and its use in routes. Indeed it is quite an old model and code had
to be cleaned a bit to improve code readability and maintenance.

In this commit we

  * remove unnecessary code examples in gamification about followers: using
    that model as example of code for goals is probably not a good idea as it
    is technical;
  * rewrite routes called by JS are simplified to better match JS
    implementation;
  * introduce computed fields to fetch related partner or channel name,
    email (partner only) and active status;

LINKS

Task 1933771
Task 2078313

closes odoo/odoo#39808

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Remy Voet <ryv@odoo.com>
Co-authored-by: jgi-odoo <jgi@odoo.com>
Co-authored-by: Xavier-Do <xdo@odoo.com>
[REF] gamification, * : rename challenge.category into challenge.challenge_category 2019-11-22T14:45:39+00:00 David Beguin dbe@odoo.com 2019-10-31T16:21:30+00:00 be3f074a910a76275ebaa576dc57f9b72f5ad4ae To ease grep in the code, especially that challenge is quite heavily used. Task ID : 1961053 PR #32594 
To ease grep in the code, especially that challenge is quite heavily used.

Task ID : 1961053
PR #32594
 [IMP] *: remove image_64 and clean views 2019-09-19T10:23:39+00:00 Sébastien Theys seb@odoo.com 2019-09-19T10:23:39+00:00 b6288e54461426d7aac6cfc549cee3e90309a093 There are too many image sizes. Since they are stored resized this takes time to generate when saving a new image, it's more rows on the attachment table, more files on the disk, ... 64px is close enough to 128px that it can be removed without a big impact on download size. It will even reduce download and number of requests when both images are displayed because now only one has to be downloaded and then benefit from cache. The difference between the two is typically around 1.5kB which is negligible these days, especially when the request overhead is around 0.5kB already, not even taking into account other factors such as latency. If a 64px image must absolutely be returned, it is still possible to pass the size parameters to the image route. But the current guideline is to handle resizing in the views when necessary. Views ===== - remove width and height attributes when existing CSS rules are overriding them (eg. `.oe_kanban_avatar` in the right context) - add CSS rules instead of width and height attributes when possible - use `object-fit: cover;` where width and height are forced to avoid distortion of non-square images - for products, use `object-fit: contain;` instead, keep ratio but without crop - add new CSS rules where the expected size was max 64px*64px before due to the image size itself - remove `img-fluid` where using size classes to avoid conflicting rules task-2060865 closes odoo/odoo#36147 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com> 
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...

64px is close enough to 128px that it can be removed without a big impact on
download size.

It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.

The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.

If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.

Views
=====

- remove width and height attributes when existing CSS rules are overriding them
  (eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
  of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
  image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules

task-2060865

closes odoo/odoo#36147

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
[IMP] *: rename image fields 2019-08-02T16:47:58+00:00 Sébastien Theys seb@odoo.com 2019-08-01T11:20:33+00:00 58a2ffa26f1a3b0f9630ce16d11b758d18e20a21 image_original => image_1920 (now resized to 1920) image_big => image_1024 image_large => image_256 image_medium => image_128 image_small => image_64 image replaced by image_1920 (when writing) or by image_1024 (when displaying what was previously the big size) + add new intermediate format: image_512 PR: #34925 
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small  => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
	what was previously the big size)

+ add new intermediate format:
image_512

PR: #34925
 [IMP] *: remove 'view_type' on window actions. 2019-06-17T11:34:17+00:00 Hiral Bhavsar hbh@odoo.com 2019-02-13T13:00:19+00:00 3cd7ed07a29c89ddf193796c20a812b9bf21e284 The old tree views don't really exist anymore, this odd pseudo-flag to dispatch between "list" and "tree" tree views has no reason to remain. Task 1937686 closes odoo/odoo#31243 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com> 
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.

Task 1937686

closes odoo/odoo#31243

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
 [FIX][IMP] various: perform small cleanup of mail templates 2019-04-23T14:26:50+00:00 Thibault Delavallée tde@odoo.com 2019-04-23T12:37:17+00:00 a7ac71ed4404aa2630619c331d725f4f545626f8 Notably * remove cdata and fix html code when necessary; * re-order fields declaration to have globally the same order in various template definition; * remove unnecessary reply-to, make user signature and auto delete fields explicit when necessary; * improve some name to ease template ordering and understanding in the template list view; Related to task 1972615 Linked to PR #32872 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> 
Notably
 * remove cdata and fix html code when necessary;
 * re-order fields declaration to have globally the same order in various
   template definition;
 * remove unnecessary reply-to, make user signature and auto delete fields
   explicit when necessary;
 * improve some name to ease template ordering and understanding in the
   template list view;

Related to task 1972615
Linked to PR #32872

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
 [FIX][IMP] various: improve recipients computation in mail templates 2019-04-23T14:26:50+00:00 Thibault Delavallée tde@odoo.com 2019-04-23T12:29:35+00:00 0b74c9ab6e2e190d3c3aed1a1c075cec36a1ad94 Purpose: use more email_formatted when possible, clean and simplify email_from, email_to and partner_to computation. Next step is to try to extract some common patterns in tools or methods in order to simplify template creation and customization. Related to task 1972615 Linked to PR #32872 
Purpose: use more email_formatted when possible, clean and simplify
email_from, email_to and partner_to computation.

Next step is to try to extract some common patterns in tools or methods in
order to simplify template creation and customization.

Related to task 1972615
Linked to PR #32872