Odoo/addons/survey/data/mail_template_data.xml, branch 14.0 The current checkout of upstream Odoo [FIX] survey: allow mail templates updates. 2020-03-06T16:36:33+00:00 Arnaud Baes arb@odoo.com 2020-03-04T17:04:09+00:00 bf242977e2c6cb27f216cff5911c531c31352a1a Otherwise, users will ending up with broken templates if they update from v12 closes odoo/odoo#47120 X-original-commit: 3f84cae060c62839e8d493c0b90539363469f5f3 Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com> 
Otherwise, users will ending up with broken templates if
they update from v12

closes odoo/odoo#47120

X-original-commit: 3f84cae060c62839e8d493c0b90539363469f5f3
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.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>
[REF] survey: on survey.survey, rename some fields to ease understanding 2019-12-05T15:21:28+00:00 Thibault Delavallée tde@odoo.com 2019-11-21T15:27:40+00:00 1e66894042a3920179f14f19b50b692845f3a004 PURPOSE As new features are about to land in survey, notably live interactions [1] and new survey building [2] performing a pre cleaning is necessary. In this PR we clean survey models by: removing unnecessary fields, cleaning some code and finally renaming models. SPECIFICATIONS: RENAME THANKS_YOU_MESSAGE ON SURVEY.SURVEY On survey.survey, rename thanks_you_message to description_done In this commit we rename thanks_you_message field. Indeed for certifications or recruitment form, "thank you" is not really the unique content you would get in a post-survey message. We therefore rename it to description_done to better indicate its use. SPECIFICATIONS: RENAME CERTIFICATE ON SURVEY.SURVEY On survey.survey, rename certificate field to certification All certification related fields on survey model begin with certification_ . Only the boolean one telling if a survey is a certification or not is called certificate. In order to ease grep and ordering it is renamed to certification. SPECIFICATIONS: RENAME PASSING_SCORE ON SURVEY.SURVEY on survey.survey, rename passing_score field to scoring_success_min ``passing_score`` field name is not really the best name we could find. Renaming the field using a ``scoring_`` prefix allow to know this field is linked to the scoring mechanism. LINKS [0] Related to Task ID 2061901 (survey models cleaning and preparation) [1] Task ID 1972640 (live interactions) [2] Task ID 2119587 (new frontend for building surveys) PR #40765 
PURPOSE

As new features are about to land in survey, notably live interactions [1]
and new survey building [2] performing a pre cleaning is necessary. In this
PR we clean survey models by: removing unnecessary fields, cleaning some code
and finally renaming models.

SPECIFICATIONS: RENAME THANKS_YOU_MESSAGE ON SURVEY.SURVEY

On survey.survey, rename thanks_you_message to description_done

In this commit we rename thanks_you_message field. Indeed for certifications
or recruitment form, "thank you" is not really the unique content you
would get in a post-survey message. We therefore rename it to description_done
to better indicate its use.

SPECIFICATIONS: RENAME CERTIFICATE ON SURVEY.SURVEY

On survey.survey, rename certificate field to certification

All certification related fields on survey model begin with certification_ .
Only the boolean one telling if a survey is a certification or not is called
certificate. In order to ease grep and ordering it is renamed to certification.

SPECIFICATIONS: RENAME PASSING_SCORE ON SURVEY.SURVEY

on survey.survey, rename passing_score field to scoring_success_min

``passing_score`` field name is not really the best name we could find.
Renaming the field using a ``scoring_`` prefix allow to know this field
is linked to the scoring mechanism.

LINKS

[0] Related to Task ID 2061901 (survey models cleaning and preparation)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)

PR #40765
 [REF] survey: remove unused or unnecessary fields to clean models 2019-12-05T15:21:28+00:00 Thibault Delavallée tde@odoo.com 2019-11-21T14:59:33+00:00 84bb9c748db26656d3ecd062183afe5f042dc569 PURPOSE As new features are about to land in survey, notably live interactions [1] and new survey building [2] performing a pre cleaning is necessary. In this PR we clean survey models by: removing unnecessary fields, cleaning some code and finally renaming models. SPECIFICATIONS: QUESTION FIELD ON SURVEY.SURVEY On survey.survey, remove question field, unnecessary related on title. Question model holds two fields for its title: ``title`` and ``question``. Question is simply a related on title, making the two fields completely redundant. It is mainly due to historical reasons, when updating models for certifications and eLearning. In this commit we keep only title field and remove the question related field as it adds unnecessary complexity to the model. SPECIFICATIONS: INPUT_TYPE FIELD ON SURVEY.USER_INPUT On survey.user_input, remove input_type and its garbage collect. ``input_type`` field exists on user input model to tell whether answer has been created through invite or through manual click on a survey page. It has been added a long time ago when surveys were either open to everyone, either closed and on invite only. Since eLearning and certification surveys access mode on surveys has evolved. Notably being able to distinguish invite from manual survey user input is not necessary anymore. Indeed what is important is the way people can reach the survey, not how they created their user input. Invitation creates token and this can be used if people effectively want to find invitation-related user inputs. Since 09ea5c7d49d544927542130078ab6e3ad5b70584 manual entries still in draft are garbage collected. Reason is still unclear as it is not obvious that tons of unnecessary entries will be created. As this seems like unnecessary optimization this commit removes that feature along with the input_type field. SPECIFICATIONS: REPLACE URLS FIELDS BY METHODS ON SURVEY.{SURVEY, USER_INPUT} On survey.{survey, user_input}, remove url fields replaced by methods In this commit we remove some remaining of URL fields that are better found using methods. Both survey and user input holds a "start" url field that is replaced by a method call ``get_start_url`` on both survey (generic) and user input (token specific) models. We also introduced a ``get_print_url`` method doing the same for the printable version of survey / user input. SPECIFICATIONS: REMOVE CATEGORY FIELD ON SURVEY.SURVEY On survey.survey, remove unused category field. Survey model holds a ``category`` field whose purpose is to be able to somehow categorize surveys according to their use. However using this field is not easy as it is hidden and is a simple selection field. Module should add their own key. Its sole use is in ``hr_recruitment_survey`` which is a niche module. Let us clean models and lessen model complexity. LINKS [0] Related to Task ID 2061901 (survey models cleaning and preparation) [1] Task ID 1972640 (live interactions) [2] Task ID 2119587 (new frontend for building surveys) PR #40765 
PURPOSE

As new features are about to land in survey, notably live interactions [1]
and new survey building [2] performing a pre cleaning is necessary. In this
PR we clean survey models by: removing unnecessary fields, cleaning some code
and finally renaming models.

SPECIFICATIONS: QUESTION FIELD ON SURVEY.SURVEY

On survey.survey, remove question field, unnecessary related on title.

Question model holds two fields for its title: ``title`` and ``question``.
Question is simply a related on title, making the two fields completely
redundant. It is mainly due to historical reasons, when updating models for
certifications and eLearning. In this commit we keep only title field and
remove the question related field as it adds unnecessary complexity to the
model.

SPECIFICATIONS: INPUT_TYPE FIELD ON SURVEY.USER_INPUT

On survey.user_input, remove input_type and its garbage collect.

``input_type`` field exists on user input model to tell whether answer has
been created through invite or through manual click on a survey page. It
has been added a long time ago when surveys were either open to everyone,
either closed and on invite only.

Since eLearning and certification surveys access mode on surveys has evolved.
Notably being able to distinguish invite from manual survey user input is not
necessary anymore. Indeed what is important is the way people can reach the
survey, not how they created their user input.

Invitation creates token and this can be used if people effectively want to
find invitation-related user inputs.

Since 09ea5c7d49d544927542130078ab6e3ad5b70584 manual entries still in draft are garbage collected.
Reason is still unclear as it is not obvious that tons of unnecessary entries
will be created. As this seems like unnecessary optimization this commit
removes that feature along with the input_type field.

SPECIFICATIONS: REPLACE URLS FIELDS BY METHODS ON SURVEY.{SURVEY, USER_INPUT}

On survey.{survey, user_input}, remove url fields replaced by methods

In this commit we remove some remaining of URL fields that are better found
using methods. Both survey and user input holds a "start" url field that is
replaced by a method call ``get_start_url`` on both survey (generic) and
user input (token specific) models. We also introduced a ``get_print_url``
method doing the same for the printable version of survey / user input.

SPECIFICATIONS: REMOVE CATEGORY FIELD ON SURVEY.SURVEY

On survey.survey, remove unused category field.

Survey model holds a ``category`` field whose purpose is to be able to somehow
categorize surveys according to their use. However using this field is not
easy as it is hidden and is a simple selection field. Module should add their
own key. Its sole use is in ``hr_recruitment_survey`` which is a niche module.
Let us clean models and lessen model complexity.

LINKS

[0] Related to Task ID 2061901 (survey models cleaning and preparation)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)

PR #40765
 [IMP] mail: add computed fields for company emails 2019-11-29T13:35:14+00:00 Thibault Delavallée tde@odoo.com 2019-10-23T12:56:36+00:00 b9a22d2f24e587894c12bf7ad289fcddcea8a823 Purpose of this commit is to give a way to access to company email and catchall with formatting. Those will be used in various automated emails. Indeed currently several templates use either ``company_id.partner_id.email``, ``company_id.email``, or even don't provide fallback values. With this commit from a company record people will be able to use * a correctly formatted catchall: ``"My Company Name" <catchall_alias@catchall_domain>`` * an email_formatted field like partner email_formatted that is either its partner-related email_formatted value, or formatted catchall if its partner is not correctly configured; Various calls to mail creation are updated accordingly. Task ID 1853147 PR #32243 
Purpose of this commit is to give a way to access to company email and catchall
with formatting. Those will be used in various automated emails. Indeed
currently several templates use either ``company_id.partner_id.email``,
``company_id.email``, or even don't provide fallback values.

With this commit from a company record people will be able to use

  * a correctly formatted catchall: ``"My Company Name"
    <catchall_alias@catchall_domain>``
  * an email_formatted field like partner email_formatted that is either its
    partner-related email_formatted value, or formatted catchall if its partner
    is not correctly configured;

Various calls to mail creation are updated accordingly.

Task ID 1853147
PR #32243
 [FIX] survey: set email_from on certification mail template 2019-09-13T10:05:15+00:00 Thibault Delavallée tde@odoo.com 2019-09-12T15:22:08+00:00 65c3be37fd284f42855e42b14953ebd9e6d9e6e7 Otherwise public users cannot receive their certification. Indeed email_from will be the one of public user which is probably not set. Task 2067872 (eLearning internal testing) Task 2058598 (survey internal testing) PR #36756 
Otherwise public users cannot receive their certification. Indeed email_from
will be the one of public user which is probably not set.

Task 2067872 (eLearning internal testing)
Task 2058598 (survey internal testing)
PR #36756
 [FIX][IMP] various: improve lang computation in mail templates 2019-04-23T14:26:50+00:00 Thibault Delavallée tde@odoo.com 2019-04-08T08:04:52+00:00 678e04c19dbfefaadd8ab6207b0bb560a3d3bfe4 Purpose: add lang definition on templates where it is missing Related to task 1972615 Linked to PR #32872 
Purpose: add lang definition on templates where it is missing

Related to task 1972615
Linked to PR #32872
 [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
 [FIX] survey: prevent certification email from being sent twice 2019-03-18T08:03:46+00:00 Aurélien Warnon awa@odoo.com 2019-02-26T09:54:11+00:00 2fb9fe279aebc24f642d1d5778cdc10012ff960f Purpose ======= The certification email template had both "email_to" and "partner_to" fields set and that implied the mail being sent twice. This commit removes the "partner_to" field to fix it. 
Purpose
=======

The certification email template had both "email_to" and "partner_to" fields set
and that implied the mail being sent twice.

This commit removes the "partner_to" field to fix it.
 [IMP] survey: rename 'Survey' to 'Certification' when relevant 2019-03-11T10:46:11+00:00 Aurélien Warnon awa@odoo.com 2019-02-28T14:45:15+00:00 7070fa32190124b1ca06b6aa3d857ca2ae148d62 Purpose ======= This commit reworks some views to rename 'Survey' to 'Certification' for a better visual integration of the new certification flow. 
Purpose
=======

This commit reworks some views to rename 'Survey' to 'Certification'
for a better visual integration of the new certification flow.