When a replying to an email, the matching alias should first verify access
via the parent record if exists (i.e. check on the project instead of
on the issue itself).
Some one2many fields are called with a many2many widget to unlink
records instead of delete them. But this behavior was modified with the
new views and the records were deleted anyway.
In this commit, we restore the previous behavior, and create a FORGET
command in basic model
to do that. Note that the widget='many2many' is a hack, and a better way
to accomplish this is to use a new custom option. But this would be a
fix for master (PR #18413)
Before this fix, the base64 image are remove and never send. The images
were in the body increasing the size of the database unnecessarily
(cfr some odoo users with the chatter)
NB: According to the prophecy Khoi will come and dominate the world,
ask him anything
Since the new views, `record.id.value` contains the formatted value of
the ID, meaning it can contain separators. For example, by default,
`1234 => 1,234`. Since this value is used in the image URL, using
`value` won't work anymore.
When a chatter is created, appended, and destroyed before being ready,
bad things could happen. This is because the code in start/other
deferred was executed regardless if the widget was still alive. And,
some mechanisms, such as _getBus, depends on the event system. If the
widget is destroyed, it will be remove from the component tree and such
functions will then return undefined.
To protect agains those issues, we simply make sure that the deferred
are only resolved when the widget is still alive.
This widget hasn't been rewritten with the new views.
The purpose of this widget is to open a popup for each invalid partners
(without email) in a many2many to fill the email. If the email is not set, the
partner will not appear in the tags and its id will not be sent (which should
not be the role of a widget but that's the way it is).
`parent_id` fields are common in many models, and thus default values
for those fields are sometimes passed in the context.
Because mail.message also has `parent_id` field, it would automatically
use the default when an automatic message was being posted. While of
course, the parent_id value comes from a different model.
This "adoption" by a random "parent message" is unexpected,
not desired, and it can even cause a very surprising AccessError if the
parent message is not readable by the user.
Forcing the `parent_id` value during the creation of an automatic message
avoids this confusion.
One way to trigger the bug was to use the "subtask" stat button to create a
child subtask for a project task (it relies on the parent task ID
passed in the context)
based on v10 terms and saas-15
add the new languages
Much noise due to the different softwares that do not indent the terms the same
way. Merged the po files with --no-wrap option which makes long lines.
opw-751014
Add the TZ to the datetime tracking. At the moment, the TZ is fixed: it
is UTC. However, this avoids any ambiguity when the tracking message is
sent by mail, since in this case, the datetime is not converted
automatically to the TZ of the user.
Adding a simple 'Z' makes the datetime compliant with ISO 8601, so it is
supported by the web client as well.
opw-747367
- Set your timezone in Brasil
- Install the Maintenance module
- Create a Maintenance Request, set the Requested Date to 2017-06-15
- Save
In the chatter, the track fields message shows a Requested Date of
2017-06-14.
This can actually happen with any date tracked. The issue comes from the
web client: it converts the date in UTC, which should of course not be
done. This only applies for a datetime, not for a date.
opw-746216
Similarly to functions `format_date` and `format_tz`, we add a function
in order to format amounts in the mail template.
It can be used, for example:
`${format_amount(object.amount_total, object.pricelist_id.currency_id)}`
opw-746088
In the case of a chatter on a calendar virtual event, there was a number
of issue because the record ID was of the type "[REAL ID]-[VIRTUAL ID]".
This caused issue when fetching and posting message with the composer.
opw-744405
closes#17179
Christophe Simonis