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).
Slug and unslug API is now available in http_routing. Indeed there is no
link to any website or any reason to not support slufigied URLs when
website is not installed. A new unslug_url method is added as a tool
coming from an embedded method from website. Doing it allows to have all
slug related methods defined at the same point.
Support of slug and unslug in qweb rendering is also moved directly in
http_routing version of ir_ui_view instead of website inheritance. This
is done in order to keep things coherent.
Some code from website about ModelConverter is also moved. Indeed both
versions of ir_http uses some kind of placeholder to store the uid
when converting urls to python. This commit unifies it by using the
website one directly in base to simplify the override.
This commit also updates all module importing slug. Enterprise modules
will have to be updated, see related commit.
`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)
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
Models inheriting from mail.thread can override this method and hook
on post message_post event and perform some action depending on the
business flow.
Future commits will use that hook to update the record after posting
a message, like updating the customer.
In 599bd509 for inline image in a mail the `Content-Id` of the
attachment was used as the file name to avoir an issue of several inline
images with the same name only displaying the first one.
This solved the issue but with it the file name when downloading the
image were lost as well as the extension which can be an issue.
This changeset refactor the code so the behavior stay the same but the
original file names are kept.
opw-725305
Currently check of alias security is directly embedded in mail.thread
routing method. In this commit we move this check in the mail.alias.mixin
class itself. Doing this allows models to extend or improve the behavior
depending on how inheriting models use aliases.
Fix some dead code. This is a fallback for linking mail attachment with
its data. The issue was not reported since a long time since this just
disable a fallback which in my tests was not used anyway.
opw-710502
When computing default recipients to mail on some records, take into
account models having a partner_email field. Indeed this method checks
for some commonly-used partner or email fields to find recipients.
This allows to avoid having custom methods in each model. This commit
adds support for partner_email email field used notably in event and
track management.
Currently if an user mentions someone in an internal note he is not
notified of any reply as replies create internal notes. This commit
ensure the author of the first note is notified of the reply even
if it is still an internal note.
Tests have been updated accordingly.
A couple of places in the processing of bounces only
accepted a single matching partner. But there could
be multiple partners matching an email address, and
we should handle them all.
There might also be no matching `bounced_thread_id`
matched by the regex, so we should guard against a
bounced_thread_id == None.
This partially reverts commits 5d746d0ac6 and
73de86c768.
The tightening of access rights was too strong: regular users need to be able
to read models and fields (to create an email templace, for instance.)
[FIX] ir_values: in `get_actions`, exclude field `code`
Remove unrestricted "read" access. To make code internally using `ir.model`
work, add a private method `_get` on `ir.model` to retrieve the record
corresponding to a model name, without access rights issue.
Change signature of method `get_authorized_fields` to make it use a model name
instead of a model id. This removes the necessity of a search on `ir.model`.
Posting on a document not inheriting from mail_thread was impossible
due to several crashes or wrongly set variables. Some cleaning is planned
in those methods as there are a lot of unnecessary computation. This will
be done in another commit. Probably.
Before this commit, 'select all' into a list view, and use an action that assign
a user_id to all the records will send n² email, because the function send_mail
use active_domain instead of the current record.
Now, we keep mass_mail mode, but simulate the case where we have clicked on
each record one by one and not all the records matching the active_domain.
So we send only one email by record.
How to reproduce:
create a action server "record.write(dict(user_id=env.user_id))"
add this action in context menu
select all records in a list and apply the action server
When you write on user_id in a model, that will automatically send an email
to the new user_id assigned.
In case where it is write in batch, that can be considered as spam.
In some case, the user will be aware from another way that with this email.
Christophe Simonis