This commit adds a feature where users can reply to messages of other
users, doing this will show a reduced version of the message that has
been replied to above the message once posted, clicking on this reduced
version will scroll to the original message and highlight it if that
message is already loaded.
task-2362251
closesodoo/odoo#77941
X-original-commit: cec2e69e832072dd699274187ddfa122e29d03f3
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
PURPOSE
We need this commit to provide a better visualization of the status of the SMS
and allow users to retry, send or cancel an SMS from the list view for a better UX
SPECS
sms.sms listview:
* reset 'failure_type' to False when its sms is resent
* 'sms status' column is moved to the right of the 'error code' column
* colors on the whole lines are removed
* the badge widget is used for the 'sms status' column
* new color for badges
'in queue': blue
'sent': green
'error': red
'canceled': gray
* new buttons are added to directly retry, send or cancel an SMS from the list view
'fa-paper-plane send now' button
only visible if the status is 'in queue'
clicking on this button should effectively send the SMS
'fa-times-circle cancel' button
only visible if the status is 'in queue' or 'error'
clicking on this button should switch the sms to the 'canceled' state
'fa-repeat retry' button
only visible if the status is 'error' or 'canceled'
clicking on this button should switch the sms to the 'in queue' state
LINKS
task-2535005
closesodoo/odoo#74354
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Purpose
=======
Purpose of this commit is to add a new group for the mail template designer.
Goal is to make roles clearer: managers edit templates, users use them. This
commit allow some designers / managers to make email template and to let
others users use those email templates.
Specifications
==============
When this feature is enabled in the Settings page, a new group is required to
modify email templates in a composer like wizard or to make dynamic content.
This allows to separate managers editing / composing templates from standard
users that use them.
If the current does not have this group, the email body will be in readonly
mode if he selected an email template. That way we force him to use the email
template that the manager made.
Technical
=========
New Group
---------
Only users in this group will be able to create / write email template or
to write Jinja code in the mail composer (including other fields like subject
in mailing).
By default, all internal users have this group. Mass mailing users also have
this group as writing mailings is about the same management level as writing
templates.
Mail Composer Mixin
-------------------
In comment mode, the template is rendered and then saved on the body field
so non-"Mail Template Editor" users can load email templates.
But in mass mode, the body of the template is saved and then rendered and
many things change the body (HTML sanitizer, web editor move inline CSS
properties, add / remove spaces...). So in this case, we can not know if
the user changed the body or not. That is why we put the body field in
readonly mode so, it is not modified by the web editor.
Jinja code detection
--------------------
To detect dynamic Jinja content, we compile the template, and we browse the
AST. If we do not have a single "Template Data" node, we assume that the
template is dynamic.
When we detect the template as static, we do not render it. That way we
avoid unnecessary rendering.
Code cleaning
-------------
Move Jinja import into tools so that it is outside of mail framework code.
Task-2187263
closesodoo/odoo#75840
Related: odoo/enterprise#20547
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When calling send on SMS, sent SMS are unlinked. If a ``delete_all`` parameter
is true, failed SMS are also unlinked.
In this commit we allow to control that behavior with two boolean, one for
sent SMS and one for failed SMS. This allows to ask to keep sent SMS and
update their status accordingly.
More control is necessary notably to enable IAP feedback on sent SMS as
an error could happen after considering it as sent. Some flows will have to
be updated to decide whether this status is necessary and if SMS are kept.
This commit prepares ground for that feature by already improving methods
and API.
Task-2634957
Prepares Task-2535005 (SMS view pimp) and Task-2560666 (IAP feedback)
PR odoo/odoo#75798
Improve cancel / set outgoing actions on sms model. This notably allows to
synchronize notifications when hitting action buttons on sms form view.
Also add an action to set as error. This will be used when having IAP
feedback on SMS sending.
Task-2634957
Prepares Task-2535005 (SMS view pimp) and Task-2560666 (IAP feedback)
PR odoo/odoo#75798
PURPOSE
Prepare code cleaning and optimization in mail, mass_mailing and SMS by
cleaning models for readability and code complexity and footprint reduction.
SPECIFICATIONS
Be aligned with mail_mail and mass_mailing naming where failure_type is used
instead of error_code.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
RATIONALE
Currently there are differences between mail and sms error management
especially when sending them in batch (mass mode). Moreover cancel
(ignored) and error (exception) states meaning is not clear. Finally
some failure types management between mail and sms can be cleaned.
SPECIFICATIONS
Meaning of ignored / error we want to enforce now is
* error: there was something wrong at sending and user has an action to
perform, i.e. server failed -> check its logs;
* canceled: invalid recipients due to contact information or mailing
configuration (blacklist, opt out, void or invalid email or phone number).
In indicates issues linked to records themselves;
In this task we also add failure information granularity on mailing traces
linked to email like what is done currently on SMS. This can be related to
mailing (blacklist, optout, duplicates) or related to recipient (no recipient,
incorrectly formatted).
We also correctly distinguish optout from blacklist when sending SMS.
SPECIFIC USE CASES
* recipient without email / number: mail / sms is set as canceled, trace is
ignored;
* recipient with invalid email (no @) / number (formatting impossible):
mail / sms is set as canceled, trace is ignored;
-> we now distinguish when possible a void email from a wrong email using
a newly-added selection key (mail_email_missing);
* recipient with email / number blacklisted: mail / sms is canceled, trace
is ignored;
* recipient with email / number that optouted from mailing: mail / sms is
canceled, trace is ignored;
* recipient with email that bounces: mail is sent and will be set as bounce
when receiving bounce in gateway; trace follow same path;
* recipient with number that bounces: not supported as currently no support
of bounce through IAP;
* mail server error, IAP error: mail / sms is set as exception / error,
trace is set in exception;
This means we introduce new failure types on mailing.trace model to reflect
those failure types
* ``mail_missing``: missing email (different from wrong value);
* ``mail_bl``: blacklisted;
* ``mail_optout``: optouted;
* ``mail_dup``: duplicated email skipped during mass email send;
We introduce ``sms_optout`` on SMS and trace models as it was merged with
blacklist previously. Now both errors are distinguished.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
Currently ``mail.render.mixin`` offers rendering tools, some of them being
based on a ``model`` field. It allows to know which model to use to fetch
records on which we perform rendering. However this field is not defined at
mixin level but in inheriting models without being clearly implemented that
way (see ``mail.template`` or ``sms.template`` models).
In order to clean this mixin it is now defined at mixin level, using a
not stored computed field allowing to define how to find this model. Sub
models are updated accordingly.
Other cleaning is done in the render mixin
* rename ``_render_template_qweb`` to ``_render_template_qweb_view``
to indicate it works on views, not on raw qweb templates;
* extract some common available variables for rendering in a method then
called / upated for jinja and qweb views;
* correctly set same rendering context for jinja and qweb views rendering;
* allow to propagate an additional context from _render_field to sub
rendering methods;
* allow to propagate options through rendering methods (notably for escaping
or safe attributes in jinja);
* allow to specify engine used to render lang;
* clean or update some docstrings;
Some tests are also added, as render mixin lacks some more detailed test to
ensure various use cases will be correctly migrated to other engines like
QWeb.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
Prepares Task ID-27033 (QWeb in templates)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
When performing an sms marketing on a model having only a ``partner_id``
field available (aka no ``phone`` or ``mobile``) it crashes due to seen
list computation (aka already contacted recipients). This is due to an SQL
query not taking into account those models as it works only for those with
a phone field.
We fix it as done in ``mass_mailìng`` app, aka fetching information on the
related partner if available.
Some tests for models using a 2many relationships towards recipients are
added. Note that this kind of model does not really support complete SMS
notification, as only the first found partner is notified. Mass SMS on this
kind of model is currently not possible as seen list is not supported. There
is no standard use case of this in Odoo codebase.
Correctly support sms marketing on sale model by defining the necessary
methods. As sale order has only a partner_id field available we have to
correctly override phone related methods for SMS.
LINKS
Task ID-2431217
COM PR odoo/odoo#71140
X-Original-Commit odoo/odoo@987d974ccbclosesodoo/odoo#71178closesodoo/odoo#71205
X-original-commit: 642816d0a819bf74927ed5aa11b6843cbb97d4df
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
There are two mixin involved in SMS notifications
* mail.thread: standard SMS sending capabilities;
* mail.thread.phone: advanced use with support of blacklist;
Both require to define fields to use when searching for phone numbers
(generally phone and/or mobile). Those are ``_sms_get_number_fields`` for
mail.thread standard implementation (in SMS module) and ``_phone_get_number
_fields`` for mail.thread.phone advanced implementation (in phone_validation
module).
In this commit we make mail.thread.phone act like a more advanced version
of mail.thread by making _sms_get_number_fields use result of _phone_get_number
_fields, and not the inverse. It allows to remove some overrides notably in
CRM having to define twice fields.
Task ID-2528169
closesodoo/odoo#71111
Related: odoo/enterprise#18428
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Right now, for failed SMS, user have to go through each record one
by one to resend the SMS, which is not ideal and user should be
able to resend SMS in batch from the list view.
This commit improves the behavior with following changes:
* Introduces an action 'Resend' which is availabe on list view of the SMS.
It enables resending multiple SMS (that are in error state). It also
displays appropriate toast notifcation to users so they know how it
worked (if few/none SMS sent successfully or there was no SMS that could
be resent etc).
* On the SMS form view, a new 'Retry' button is introduced, visible on SMS
whrich are cancelled or in error state. It pushes the SMS back in sendng
queue (outgoing state).
* 'Cancel' button on form view now also appears in error state.
* Uses the state-decorations on the list view for better identifications
of the records (info for outgoing, muted for canceled and danger for error
state).
taskID-2465233
closes https://github.com/odoo/odoo/pull/67502
Currently phone_sanitized computation on lead model works only if crm_sms
is installed. Indeed an override of ``_phone_get_number_fields`` is missing.
However ``_sms_get_number_fields`` coming with ``crm_sms`` and its ``sms``
dependency hides the issue as those modules are auto-install. However if
``crm_sms`` is uninstalled phone_sanitized is not correctly computed anymore.
Task ID-2528169
Oversight of odoo/odoo#45315
X-Original-Commit: odoo/odoo@45ae2922e5
Now that recipients in notification process are always partners due to
simplification of MailFollower model we can safely simplify the structure
used to collect and propagate recipients information.
Before this task it was a dictionary with a list of partner related data and
a list of channel related data. It is now simply a list of partner related
data, leading to various code cleaning.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
As there is no way to add channel-based follower anymore we can remove all
fields and code supporting this feature. Notably we can remove ``channel_id``
field on ``mail.follower`` model as well all code using it, notably compute
methods.
In this commit we also make ``partner_id`` field required as now followers
are always partners. Email, name and active fields are now simple related
fields on the partner.
Code computing data about subscription is also updated and simplified. As
we do not have channels anymore but only partners all custom SQL queries
are now simplified.
JS models for Discuss are also cleaned. Following python change, JS models
are simplified to match the backend models. Channel_id is removed, partner_id
is now required, and various code is updated according to the simplified
model.
Side note: we could probably get rid of specific index on ``partner_id``
field. However we have to ensure we never search for followers without being
in a model / res_id context. This will be done in another cleaning step to
be sure performance are not broken.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
A bit of history. Link between a message and its recipients has been added
at first mail refactoring towards a Chatter / Discuss feature. It was done
in v7 at d64f3c9783 with the base addition of mail notification model (lots
of commits follow that one but that's the first one about notification).
Due to some people thinking that it was unnecessary to keep a model for
notification it has been removed in v9 at 88b8cd0587. Notification table was
renamed from mail_notification to mail_message_res_partner_needaction_rel.
It was proven to be a mistake even if those "some people" were warned and
model made its way back to Odoo in v10 at 72dfcae2a4 . Table name mail_message
_res_partner_needaction_rel was kept to ease migration and backward
compatibility.
It is now time to complete the circle and rename it to mail_notification.
SPECIFICATIONS
Rename ``mail_message_res_partner_needaction_rel`` to ``mail_notification`` .
RIP JEM.
Never forget.
LINKS
Task ID-2477444
Prepares Task ID-2377974 (trace management cleaning task)
Prepares Task ID-2070632 (channel members main task)
Prepares Task ID-2419762 (channel members followup task)
COM PR odoo/odoo#67382
UPG PR odoo/upgrade#2245
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
This commit adds user feedback in the form of a message logged on the related
document (mailing.mailing) when testing a mailing/sms.
Before this change, when sending an email to your own mailbox for testing
purpose, or when sending an SMS to your phone, you did not get any interface
feedback on whether it worked or not.
Now, a logged message will show if it's successful and if not, explain why it
failed with a short error message (no IAP credits / misconfigured outgoing mail
server / ...).
In addition, email and phone inputs are now split on the '\n' character instead
of a coma, which allows easier validation of the email addresses.
Task-2375526
closesodoo/odoo#63421
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Problem
-------
_search_is_mail_thread_sms is looking for ir.model
in the database and then fetch them from the registry
without verification. This can lead to key error
when a model is present in the database but not in
the python anymore. This situation can happen
after a migration.
Solution
--------
Check the model is present in the registry
closesodoo/odoo#60001
X-original-commit: 448626d86a1f06b9f8a7a88111f7cb01600488cd
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Clean and improve IAP tools integration in Odoo. Introduce bridge modules
to extract common features, notably for CRM and Partner.
SPECIFICATIONS
In this commit we reorganize IAP module to better understand its content
and ease future cleaning
* have models separated from tools;
* rename some tools to find their grep. An iap_ prefix is added to ensure
we don't clash with other global functions or methods;
* perform some linting;
To provide backward compatibility support we keep some import in init file of
IAP addon. Standard code is about to be updated but we want to avoid too
much issues when migrating code to 13.5 . Compatibility layer will be removed
after v14 final freeze.
LINKS
Task ID-2248367
Community PR odoo/odoo#53214
Enterprise PR odoo/enterprise#11258
Upgrade PR odoo/upgrade#1363
IAP PR odoo/iap-apps#191
While creating contextual action for an sms template, the composition mode
may be decided on the fly, based on number of records and on context the key
`default_composition_mode`, which is set to 'guess'.
It used to work before a recent refactoring[1], because the composition
mode was changed in the default_get, and was being set to appropriate
value instead of 'guess'.
After this refactoring, the composition mode is not being set in the
default_get but is being computed, so the key `default_composition_mode`
tries to set the composition_mode selection field to 'guess', which is not
available in the selection values, resulting into traceback.
This commit fixes the issue by renaming the context key(removing 'default'
prefix) to avoid setting the mode directly and instead let the compute method
decide the composition mode based on context key and number of records.
[1] - https://github.com/odoo/odoo/commit/e02137c48562d824e3e01054e31dae383e5843e2
TaskID - 2286959
closesodoo/odoo#54938
X-original-commit: 2b9ea3d93445e05cb0440aab33f2bf9e066b0fa5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Taking a self and a separate action seems unnecessary given self *is
an action*.
Only do this change for the "new" naming scheme, so the old one keeps
working as-is.
There is no reason to call these directly, in fact it's not really
possible to do so as they expect an `action` object as first
parameter.
* warn against the presence of rpc-public runners
* move runner selection outside of ``run``
* improve doc a bit maybe
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Bug
===
Go to CRM, in the lead list view and select a lead without
phone number. Then, click on the action "Send SMS Text Message".
Then, enter in debug mode and go to the SMS form view. The
number will be "0" instead of being empty.
Task-2244195
closesodoo/odoo#51389
X-original-commit: 8805c16bfb1bfb001e674d9a2755ad0e98fcb834
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since January 2020, users are required to validate their IAP account via
SMS code validation. This new behaviour needed to be properly ported to
the client to correctly inform the user.
This commit adds support of a new failure_type: 'Unregistered Account'.
Task #2209567closesodoo/odoo#48512
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When no valid phone number was found on a record, and when using _message_sms
directly, no SMS and no notification was created. You could therefore think
everything was ok while it was actually not.
Instead we now create failed notifications. It allows to be notified of it
and fix numbers through cancel / resend wizards.
Task ID 2244192
closesodoo/odoo#50486
X-original-commit: baecdfaa2d31714a20d1fb8af7799af1805cd939
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When no valid phone number was found on a record, and when using the composer
in single recipient mode, you had a crash at sending as composer tried to
write on a field called False.
Instead we just take the first available phone field of the record. As they
are all void we can update them safely.
Task ID 2244192
X-original-commit: 2306d7d79d8e64597912f15365cede7473589731
In this commit we order fields more logically to ease reading and prepare
future modifications. We also rename the class and some field strings to
be more user friendly.
LINKS
Prepares Task ID 2238597 (clean notification models)
Prepares Task ID 2083854 (improve mass mailing technical flows)
PR #49891
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
The purpose is to have more common code for failure and notifications, with less
override in `sms` and `snailmail`.
task-2176017
closesodoo/odoo#44170
Related: odoo/enterprise#9140
Related: odoo/upgrade#918
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
PURPOSE
Merge rendering tools used in mail and sms templates as well as partially
in mailings and move them directly in mail.render.mixin.
SPECIFICATIONS
Move tools related to language computation from mail.template model to the
mail.render.mixin. It allows to update both
* mail.template: simply update calls accordingly;
* sms.template: remove code doing what is now available through mail.render
.mixin inherit;
Lang field is moved to mail.render.mixin as it is used notably for the language
computation. It therefore adds the field on mailing.mailing model although
not used currently.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
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
Clarify mail.template, mail.render.mixin and sms.template code organization.
SPECIFICATIONS
Reorganize fields according to their main use.
Remove an unnecessary onchange in mail template model. As "model" field on mail
template is a computed field its computation is sufficient.
Add some docstrings and code separations.
Prepare future code change.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
After this commit
* the SMS button is visible next to a phone number in mass_mailing, and
mass_mailing_sms
* when sending an sms to a single contact, its phone number is now an
editable field in the wizard and there is a warning if the number is
invalid;
* if operator updated the recipient number, update record number according
to the new number only in single recipient mode (aka, solving number
issues directly from interface);
LINKS
Task ID 2088303
Community PR odoo/odoo#40482
Upgrade PR odoo/upgrade#873
Co-Authored-By: Florimond Husquinet <fhu@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Purpose is to improve information given back, adding notably
* whether the value comes from the customer (partner_id field) or directly
from the record we are looping on;
* the actual field used when no specific field is enforced;
LINKS
Task ID 2088303
Community PR odoo/odoo#40482
When we send a SMS in the contact form view, exact body is sent by SMS and
displayed in chatter. If some manual HTML is added chatter will display it
as HTML while sms receive HTML tags.
We want that the SMS content in the chatter is the same as the SMS sent and
that HTML tags are removed to avoid being interpreted.
To achieve that goal we call html2plaintext in ``_message_sms`` and in
``prepare_log_body_value`` that are two entry points to send SMS.
We also update ``html2plaintext`` to strip result in order to avoid having
unnecessary spaces left.
Task ID 2126123
PR #40441closesodoo/odoo#46362
X-original-commit: 4b7b14a5ea5e6ab521838c01813fa478154682fd
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue
- Install Calendar
- Technical > SMS templates > Calendar reminder > Add context action
- Calendar > Tree view > meeting > action is there
- Delete SMS template and/or uninstall calendar_sms
Template deleted but action still there with a traceback
when you click on it.
Cause
The action is never deleted.
Solution
Delete the action when the template is deleted.
OPW-2161653
Closes#42328closesodoo/odoo#43984
X-original-commit: eb95f06f19c60babc775de57813a293ffc35c581
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Below points are improved in automated action
- Set no_create on model_id, crud_model_id, partner_ids, and channel_ids
- Set widget many2many tags and change string for trigger_field_ids
- Rename 'Trigger Condition' to 'Trigger'
- Change on_change_fields into a many2many to ir.model.fields
- Set 'Hours' as default of field trg_date_range_time
- Rename label of crud_model_id to 'Target Model'
- Rename label of sms_mass_keep_log to 'Log as Note'
- On creation of template set the default model
- Hide the 'Security' tab
- Set no_create on fields resource_ref and col1
- Make 'value' readonly when col1 is not set
- Rename 'Link using field' to 'Link Field'
Task-2082503
closes odoo/odoo#39622
Closes: #39622
Related: odoo/enterprise#6515
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
PURPOSE
Upgrade the "mass_mailing" and "mass_mailing_sms" modules with a dynamic
placeholder generator as it already exists in "mail module" as depicted in
https://www.screencast.com/t/cnFA0gIY.
SPECIFICATIONS
As duplicated code already exists for that and that a third version of this
code has to be added, instead create a mixin for this dynamic placeholder
generator to avoid code duplication.
Thereby
* a mail.render mixin for the dynamic placeholder generator must be
created in mail;
* dynamic placeholder generator code present in mail.template.py must be
moved to that mixin and replaced by a simple inherit;
* use the mixin in
* mail templates: mail.template.py (mail module);
* mass mailings: mailing.py (mass_mailing module);
* sms templates: sms.template (mass_mailing_sms module);
In a near future, some code will be added in this mixin, notably the template
rendering that could be moved outside of mail.template core model and moved
in that rendering mixin.
LINKS
Task ID 2070612
PR #36722
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Batch of 10 text messages was ok for testing. Production environment should
be able to handle more of them.
LINKS
Task 2076366 (send now)
Task 2067873 (template access)
PR #37298
PR odoo/enterprise#5750
sms, in the form view of sms composer (mass composition) : we got a blocking
message when we validate the composer sms with records which doesn't have a
phone number.
However we generally explicitly handle void numbers: in composer in comment
mode there is an User Error, and mass mode has specific error code to put on
sms records telling number is void (and sms is in error, meaning it will not)
be sent.
As sms record is required notably for mass mailing traces and marketing
automation traces we have to keep sms records with void numbers. We therefore
remove the required attribute on sms record.
Task ID 2073016 (sms fixes)
PR #37185
- Change the name of "Mass SMS" by "SMS Marketing"
- Improve the Mass Mailing views (kanban, form)
- Improve the Mass SMS views (kanban, search, form)
- Hide the sanitized numbers from views (sometime replace by mobile)
- Fix demo data of sms
- Explain the language field of sms template
- Improve the render of the sms composer wizard
TASK_ID : 2053631
In the SMS template, we add the ability to create (and remove)
a contextual action on the targeted model from a sms template.
We change the sms composer to guess the composition mode,
and then to be usable by contextual action. The guess compostion mode
works differently if there are multiple target
selected (mass) or a single target (comment).
TASK_ID : 2053631
- Cancel button in the sms form view not related to a action :
When we click on the cancel button of the sms form view, get traceback.
Fix the issue by adding the cancel action in sms model.
- Mass mailing contact - False as the display name :
The display name was the mail address but when the contact didn't have
mail address a ugly False was print to described the contact (form view).
Then change the _rec_name to print the name as the display name.
- Fix SMS composer for the res.parnter tree
Only the first record was truely selected when open the sms composer
(mass) from the tree view of partner. Fix that by bind the actives_ids
in the context and also fix the names of related actions.
TASK_ID : 2053631
This is a performance optimization: modifying a regular record will not
trigger some recomputation on a transient record. Most transient
records are simply waiting to be garbage-collected, so there is no need
to keep their fields up-to-date.
closesodoo/odoo#35909
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Samuel Degueldre