*: calendar, im_livechat, mail.
Before this commit, the legacy session was a dependency for the bus
service. This was problematic since one would need to import a bunch
of legacy files to fulfill this dependency in order to use it.
This commit removes this dependency. In order to pass parameters to
the `bus_service`, the `bus_parameters` service is now used.
closesodoo/odoo#110247
Related: odoo/enterprise#35974
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, in the form view to schedule an activity, the
"Recommended Activities" were displayed as a column, one per line.
With this commit, recommended activities are displayed on the same
line.
To open the Schedule Activity form view, open a project task, and
click on the tab Activities in the chatter (for instance).
Bug reported on the feedback pad after migrating odoo.com to 16.0.
closesodoo/odoo#110350
X-original-commit: cc82ccb94a8b52f09e797fc0645da32bc7481126
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, all pending changes in a form view were lost
when the user added/removed/edited followers or created/edited
activities. In these cases, we want to reload the record, but we
also want to keep local changes. This commit restores the behavior
of previous versions.
Task 3132939
closesodoo/odoo#110246
X-original-commit: f3697e71c2d14e66509ab04bdccf3ef656cd9c8f
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The mail code had to override both new and old form views to add the
chatter feature. Since we converted (almost) all uses of the legacy
form view to the new owl views, the old override is no longer necessary.
This commit removes it, and also removes the 'legacy_form' entry in the
registry so all screens should fall back to the new form view, which is
stable.
closesodoo/odoo#110168
Related: odoo/enterprise#35924
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Owl last update fixes the leaking `this` in rendering context of
templates called with `t-call-context` [1]. Since [2], we use the
`t-call-context` directive to control the rendering context of
templates compiled from an arch (e.g. in form and kanban views).
We can now better control what people use in archs, where we don't
want them to access js implementation details, as `this` is no
longer available.
However, the component instance still needs to be accessible in
the compiled template. We thus add the `__comp__` key in the
rendering context. Since we do not want people to access it in
archs, we add a check in the view validation that this string
isn't used in dynamic attributes.
[1] https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6
[2] https://github.com/odoo/odoo/commit/4c5b867ff6b0b674cb83d1a1262ae354ebaa6d57
X-original-commit: 264f313012aa99449d1576ae1110252c13755142
Part-of: odoo/odoo#110196
Currently when using the composer excluded emails are computed when the target
model inherits from the blacklist mixin. This behavior can now be deactivated
through a new field 'use_exclusion_list', like what has been done in SMS
composer.
Task-3132710 (Mail: Configurable composer)
Part-of: odoo/odoo#99482
Currently when using the composer to create a mass mailing emails are sent
directly, unless scheduled date is in the future.
With this commit it is now controllable through a field like what has been
done on SMS composer. Its default behavior is the same as before
* posting on a monorecord: force send notification emails;
* posting on multirecords: use the queue (force_send=False parameter given
to message_post and propagated to _notify_thread);
* mass mailing: use force send to send emails directly;
Usage of mail_notify_force_send context key is also removed when possible
as it is a standard parameter of posting API.
Task-3132710 (Mail: Configurable composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Correctly update 'auto_delete' field
* add missing update in onchange, to either take value from template, either
fallback on default_get values as other fields;
* in comment mode, actual value for 'auto_delete' is True by default. Composer
value was not used and bypassed by a context value being True by default.
Context key support is removed, correctly replaced by the composer field
value itself;
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Change 'auto_delete_message' into 'auto_delete_keep_log' that has the inverse
meaning. Indeed it is unclear what 'auto_delete_message' really does. It is
used when automatically removing emails sent through mass mailing, to know
if message created through inherits are kept or not. Purpose of keeping them
is to have a log on the document. Deleting the message therefore removes the
log.
In this commit we change the meaning to something positive, keeping logs being
clearer when choosing which option to activate. Functional usage of the field
itself does not change with this commit.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Remove 'is_log' field on mail composer. Indeed its usage can be globally
replaced by using the 'note' subtype when posting. It is now better matching
the result of using the log a note mode of chatter.
Posting with a False subtype_id already automatically converts it into a
note subtype in 'message_post'. It is now done directly at composer level
to lessen magic and have more control on final output.
In case of outgoing emails subtype has no usage, as notification process is
not called. It is therefore forced to False when creating the mail records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Update report_template field on template model to be a many2many field instead
of a many2one. It allows to attach multiple dynamic reports to a given template
instead of being limited to a single one.
Name should now come from the report itself, which should be considered as
complete by itself. Template cannot override report naming anymore.
Task-2868153 (Mail: Allow multi reports in mail templates)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Purpose of this task is to correctly support scheduled_date from template on
both comment and mass mode in the composer.
It is currently mainly supported at template level, when using a template
to directly send emails. In this commit we add a field on composer that
takes the value from the template, and propagate it to the mail or messages
created when validating it.
As most template fields it can contain inline template code to be rendered
dynamically on target records, hence using a char field. Its rendering
is done using template that calls _parse_scheduled_datetime. It allows
to have an UTC and timezone agnostic value.
SCHEDULED_DATE SUPPORT
When posting a comment, scheduled posts uses the 'mail.message.schedule'
mechanism that creates the message but send notifications later.
When sending a mailing, emails have a scheduled_date set. As the 'send'
method does not check for scheduled_date (only the cron queue) we have
to filter emails scheduled in the future before calling the 'send'
method.
Task-2993872 (Mail: Support scheduled date in all composer flows)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Support a real res_ids field on mail.compose.message model. Instead of relying
on active_ids from context, store it once for all at composer level and use
it in code. Active_ids usage is still done at default_get level, using it to
populate the field.
Improve usage of domain, renamed to res_domain to match other document related
fields naming. Add support of a res_domain_user_id field allowing to set the
user from which the domain should be evaluated.
Composer now runs on a list of IDs. Mass mail mode and comment mode are now
distinct from running on a singleton or on more records. Rendered or raw
mode is not triggered by
* mass mailing mode: always display raw mode, whatever the number of records;
* comment mode: display rendered mode when having a single record (like the
previous comment mode). Display raw mode when having either no records
either at least two records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Remove deprecated "mass_post" option from composer. It is either a comment
(using message_post) either a mass mail (creating emails). Mass post was
anyway nor used nor really supported. It will be replaced by supporting
having a comment on several IDs (batch comment mode, posting a message
on several records instead of being limited to one as currently).
This cleaning also allows to remove the 'notify' field that was an option
used for mass_post. All this should be supported through subtypes and
correct choice of post / mass mailing.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
When trying to use the composer without related records in comment mode
message_post raises, as record is mandatory (ensure_one). In this commit
we make this raise explicit in the composer itself, in order to be able
to assert the behavior.
In mass mail mode, having no record to mail is possible and the composer
simply skips the mail creation. Indeed when doing mass mailing, notably
with crons, records might have been updated / removed and the composer
should not crash, just produce nothing.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
Purpose of this commit is to cleanup context usage in composer
* remove now dead 'custom_layout' context keys that was present mainly for
compatibility until Odoo v15. You should now correctly use default value
for 'email_layout_xmlid' field like every field;
* remove 'mail_auto_delete' context key, not used anywhere in codebase.
Auto-delete field of composer will be improved soon so that setting it
as every field will replace the context usage;
* remove usage of self._context, to use self.env.context;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Purpose is to rewrite value generation as code is messy with a lot of dict
updates, rewriting key on top of existing keys until reaching the final value.
In this commit we better split computation, to have computation that is static
(currently, posting a comment as composer holds final code) separated from
dynamic computation (posting a mass mailing, as rendering is done based on
qweb or inline template value).
It allows to better understand how composer and template fields are used when
sending emails or posting messages. This commit should not change anything
functionally, even if some values are weirdly computed. Future commits will
improve support of composer / template fields, notably through computed field
and less cross computation.
Also split sending methods: do a mailing in batch in case of mass mailing
(allowing commit per batch), and simply loop on records to post a message
in case of comment (or mass post).
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Now that template generation methods have been cleaned we can cleanup calls
done in composer. We notably
* make methods private, improve their naming and docstrings;
* better support input / output of asked fields;
* be more coherent with composer fields and template fields usage;
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Composer Onchange to Editable Computed Stored)
Part-of: odoo/odoo#99482
Purpose is to ease understanding of those default values and prepare move
towards editable stored computed fields by rewriting a bit the code to better
understand its purpose.
While being at it, some tests introduced recently are moved at their right
place now that everything is ready to rewrite the posting API and the
composer. Some tests are added to ensure notification-specific methods are
called along with the newly-introduced '_message_compute_subject', aka methods
to add custom header and custom mail values.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in compo
Part-of: odoo/odoo#99482
Purpose of this commit is to move methods to better prepare future changes.
Currently onchange code, value generation and tools for email management
are mixed, which leads to the file being quite messy.
Separate methods generating mail or message values, from methods doing
data marshmalling.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
When computing recipients based on template we generally create new partners
based on emails. This is due to the mail framework managing mainly partners
and not low level emails.
This code is currently sequential: fetching or creating partners one by one
based on found emails, for each record. This is highly inefficient when
sending emails on a lot of records based on templates.
Purpose of this commit is to improve code and performances by batching. We
do queries in batch: one search for all records, create partner in batch. This
leads to code being a bit more complicated to correctly remember and dispatch
again emails and partners to the correct records.
Task-3034875 (Mail: Speedup and batch partners find or create with templates)
Part-of: odoo/odoo#99482
Purpose of this commit is to extract fields generation on template for fields
not belonging to recipients or attachments in sub-methods. Code is cleaned to
better support parameters and be easier to call. It can now be called
independently from the main ``_generate_template`` method.
First sub method is dedicated to 'scheduled_date' which is dynamic and has its
own post processing (to be UTC agnostic as expected by ORM). Second one is
dedicated to static values coming directly from template without rendering.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Purpose of this commit is to extract attachments generation on template in
its own sub-method. As it contains code specific to attachments, better
have it separated from the main global generation method. Code is cleaned
to better support parameters and be easier to call. It can now be called
independently from the main ``_generate_template`` method.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Purpose of this commit is to improve recipients generation on template.
Code is cleaned to better support parameters and be easier to call. It
can now be called independently from the main ``_generate_template``
method. Docstrings are updated.
Changes
* removed support of ``tpl_force_default_to`` context key used to somehow
simulate the check of "use default recipients" (??)
* removed support of ``tpl_partners_only`` context key used to force to
find or create partners based on emails generated by the template. It
is replaced by a parameter to propagate;
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Currently some value are always computed and added even if not asked by the
caller. As asking a template to render some fields is now used notably for
a subset of fields (subject and body, from / to, ...) there is no need to
automatically add other irrelevant information.
Main callers already filtered out returned results (notably composer). However
better avoid computing / rendering unnecessary stuff directly at template
level.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Purpose of this commit is to prepare further improvements in template and
composer rendering methods. First step is to
* make them private;
* correctly name parameters (notably rename fields to render_fields to avoid
collision with odoo.fields);
* remove the "single / multi" mode. This is a relic of old implementation
when rendering was done mainly record by record and sometimes by batch.
Now everything should be batched;
* split some lines to ease future diff in upcoming commits;
* improve some docstrings;
Next commits will rewrite and split parts of ``_generate_email``.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
'email_from' fields are not necessary on 'sale.order.cancel' and 'survey.invite'
as anyway we always use the current user's email and field is not present in
form view. Override of default_get to raise about invalid email_from is not
necessary as anyway it raises when posting the message. Giving author_id to
message_post is sufficient as it computes email_from based on author when given.
Add 'render_model' in views, as it is part of the domain given to 'template_id'
field of composer mixin. When missing, also add 'lang' and 'template_id' that
come from the render mixin.
Use '_render_field' when possible instead of '_render_template' as its API
is simpler and uses field definition for rendering parameters.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
A method ``_message_set_main_attachment_id`` exists to handle main attachment
reference, used notably in discuss and accounting. It is now called inside
``_message_post_after_hook``, so that it is part of the post processing after
having posted the message. Its API has been updated so that attachment_ids is
now a real list of ids, which is clearer.
A wrong override of '_message_post_after_hook' dealing with parameters is
cleaned while passing by.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SPECIFICATIONS
Update methods parameters to look more like 'message_post' definition. Add
docstrings to explain parameter usage. Cleanup some parameter we do not
want. Add a api.returns on message_notify to wrap the value in case of external
call, as this method is public, like message_post.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
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
When calling "_render_template_qweb_view", parameter can currently be an
XmlID or an id. It can now be a recordset, allowing easy calls from Odoo.
Slug is also added in evaluation context to prepare further cleaning in
message_post helpers.
Some error messages are also improved while passing by.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Purpose of this commit is to clearly check input of ``message_post`` method
and its main helpers in order to prevent wrong usage of message post API.
Some values used to populate message fields should not be set directly when
posting or logging messages. Indeed they may be part of other process (like
notification process managed by ``_notify_thread``, or could be setup by
custom routes like 'reaction_ids', or custom usage of 'model' and 'res_id'
that could conflicts with record on which methods are called).
We therefore add checks and cleanup in those methods to be sure the API
is used as intended and avoid unwanted side effects.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Purpose is to be able to create find or create partners in batch based on a
list of emails. When sending email in batch, notably using templates, doing
sequentially a search or create for each potential email to contact is not
efficient from computation point of view. This commit introduces a new batch
method for that purpose.
If no valid email is found for a given email, it is used as it to try to
find partners with same invalid email and/or keep the value in order to
allow updating it afterwards. Notably with notifications resend it is
possible to update emails, if only a typo prevents from having a real
email for example.
Falsy emails do not create partners as those have no real interest.
Task-3034875 (Mail: Speedup and batch partners find or create with templates)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
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
Fix usage of CCs when sending emails. Currently CCs are added to all outgoing
emails, which leads to unnecessary spam. Recipients are currently computed like
* create an outgoing email based on 'email_to';
* create one outgoing email / partner in 'recipient_ids';
* add CCs to all outgoing emails;
They are now sent only once, either with the email_to if given, either as
standalone. That way partners receive specific emails (due to tracking and
partner specific links management), email_to / email_cc are sent on their own.
Task-3093268 (Mail: Stop spamming CCs)
Prepares Task-2684479 (Mail: Better report errors when sending emails)
Part-of: odoo/odoo#99482
In this commit we add some logs when we fail to evaluate the 'headers' field
on a 'mail.mail' record, used to populate the headers of outgoing emails.
Some tests are added to ensure we do not crash if headers is malformed, and
to cover the feature itself as it was still not really done.
Task-2710804 (Mail: Clean MailThread Posting API)
Task-3093268 (Mail: Stop spamming CCs)
Prepares Task-2684479 (Mail: Better report errors when sending emails)
Part-of: odoo/odoo#99482
RATIONALE
When sending a ``MailMail`` some data preparation is done. This is done
directly in ``_send`` and in sub-methods. As a given MailMail may lead to
several emails being sent we have to go from a mail to a list of emails
to send :
* one email for ``email_to``. They all receive the same email, as those are
just a list of emails to contact and no specific post-processing is done;
* one email for each partner in ``recipient_ids``. It enables a partner-based
update of the body, for example for links or traces in mass mailing;
SPECIFICATIONS
In this commit we move code so that all preparation is done in a sub-method
``_prepare_outgoing_list``. That way it can be cleanly overridden to add or
modify values before sending the actual emails.
This commit does not change behavior and calls done to ``build_email``. This
will be updated in the next commits, notably to improve "cc" management.
Task-2710804 (Mail: Clean MailThread Posting API)
Task-3093268 (Mail: Stop spamming CCs)
Prepares Task-2684479 (Mail: Better report errors when sending emails)
Part-of: odoo/odoo#99482
Composer holds code to check recipients email and avoid sending emails when
recipients do not have valid emails. Purpose is to avoid bloating the email
queue with emails that are about to fail.
It is done by analyzing recipients of emails, aka checking 'recipient_ids'
value before creating the mail.mail.
When being in comment mode, this code has no use as recipients are computed
by the notification process, not by the composer. We can therefore skip this
part. It adds the 'state' and 'failure_type' values that are used on mail
model, but not on messages.
The same kind of processing could be done in notification process to avoid
sending unnecessary notifications, but this improvement belongs to another
commit and task.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
In this commit we add a method to check MailMail, based on a given record.
When having duplicates to differentiate in a given mailing, having just
recipients is not sufficient as multiple emails may match a given recipients
list. Checking model / res_id is another method for finding emails.
This will be used notably to add tests for exclusion list and duplicates
management in standard mail composer, outside of mass mailing context.
While being at it, use subTests when having loops checking values. That
way it is easier to fix tests that have several failing values in the same
global assertMailMail_* .
Task-3132710 (Mail: Configurable composer)
Part-of: odoo/odoo#99482
In this commit we correctly set 'error_msg' field as computed. As it was not
defined as computed, it was not really updated and therefore not displayed
in the preview form view. It is now the case.
ValueError are now also catched, for example when having badly configured
'partner_ids' field we may face this kind of error, which is now logged
in the preview wizard.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Sometimes the previewer crashes in rendering with cache-based records, hence
trying to check directly the id of the related reference record.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Mail holds an helper function to convert datetime from a char input into a
datetime value. It is used notably when having to store a datetime value
(e.g. on a mail_mail) from a string generated by templates with expression
like ``{{ datetime.datetime.now() + datetime.timedelta(days=2)}}``.
In this commit we explicitly remove microseconds, as otherwise we end up with
something that the web client cannot parse, not speaking of even going into
server side storage with this value not matching the expected format.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Enlarge selection fields of record and language in the template preview form so
that the labels are not truncated.
Task-3098782
closesodoo/odoo#110075
X-original-commit: f1ac110cb71d982acd9d6cdbccaf6d2415a38736
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
before this commit, there is no form view defined for the mail.guest model and on accessing these record from Guests menu under the settings, is returning odoo generated form view.
after this commit, clean form view will be displayed on accessing the Guest menu.
closesodoo/odoo#109826
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
To Reproduce
============
- add event on calendar
- edit the event and remove the user from participants list and add another one.
- save the record -> traceback
Problem
=======
we try to read `hasReadAccess` from `this.followedThread` that is `null` in this case.
Solution
========
check if `this.followedThread` is `null` or not
opw-3126545
closesodoo/odoo#109721
X-original-commit: f9a23af63bb5fe882f0d42f06ef1406910836115
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Issue: `node.data` is an unescaped text content and used as an escaped
content just after (set `innerHTML`) which remove some of the escaping.
Without the fix, the 2 new first assertions would fail:
- first one with 'https://example.com/?¤cy_id' instead of
'https://example.com/?&currency_id' in the text node
- second one with `&` replaced by & and `>` replaced by >
other assertions ensure that use case before the fix (special char and
URL regex, smileys, ...) still work the same after the fix.
opw-2525028
Fixes#70485closesodoo/odoo#109357
X-original-commit: 4938af5dd8bfb4ea0722e3de8340ff6437329b48
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
Current behavior
In the recruitment module, if you set an email template for the first step of
a job recruitment process you cannot send any other email using the full
composer. This happen because the partner type goes from 'contact' to 'private'
and this type cannot be set as recipient in the full composer.
Steps to reproduce
- Go to any job recruitement and set an email template for the first
step
- Go on the website and apply for this job
- Go back to the job application and send an email using the full
composer, the email is not sent to the applicant. And the applicant
is not added to the followers.
Fix is to somehow improve support by adding asked partners from default in
context.
Note that this does not change anything from ACLs point of view, as trying
to access private partners without the necessary group or ACLs will raise an
access error anyway.
Also note that private partners defined on a template are still stripped
as they do not respect the new (nor the old) domain. That would be tricky
to solve, better not use private partners in templates.
opw-3010308
closesodoo/odoo#109451
X-original-commit: 12b25f21216b11511d5fed22fb3564d9dc297559
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Part-of: odoo/odoo#109522
Co-authored-by: Robin Engels <roen@odoo.com>
Add tests showing current behavior of partner_ids fields on composer when
dealing with private partners. Some use cases are added as unit tests
* default_partner_ids: coming notably from suggested recipients;
* template usage adding a partner (e.g. partner_to);
* when not having the rights to see private partners, access error should
be raised;
* mail gateway when a private partner sends an email;
X-original-commit: 2153eec790b730761fe50d6bea5cd4bacedce97a
Part-of: odoo/odoo#109522
Co-authored-by: Robin Engels <roen@odoo.com>
Since the refactoring of the activity view, luxon is not in the
rendering context. Resulting in crashing in some activity views
that used luxon in their template.
- Go to Appraisal
- Switch to the activity view
- Create a record in this view -> crash
Now, luxon is in the rendering context.
closesodoo/odoo#109153
Signed-off-by: Luca Vitali <luvi@odoo.com>
tsm-odoo