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`.
This is a manual forward-port of commit 03ac47b9d7
Currently when someone is added as follow to a document default subtypes
are computed if no specific subtypes are given to the subscription. However
if internal subtypes are set as default those are added to all new
followers. It should take into account customers and shared users and avoid
adding them internal subtypes.
Customers and shared users are not notified of messages using an internal
subtype. So currently there is no information leak. However with this fix
we ensure internal subtypes are not followed by external people even if
no notification is created.
Compared to original commit tests are slightly updated because there are now
default internal subtypes in data. Not in 10.0 and previous versions.
When creating a mail.mail without giving a mail_message_id, a new mail.message
is created. It does then through _notify that notifies people of the message
creation. This leads to mail being sent two times, one when sending the
mail.mail, one when sending the notification.
This commits fixes that behavior. When creating directly a mail.mail without
giving a mail.message, call to _notify is bypassed. This way either an email
is created, either a message that has to be notified is created, but not both.
When Odoo sends emails their Message-Ids are either generated by Odoo or
use the original Message-Id in the case of an incoming email going through
the mail gateway.
When the mailgateway handles replies to those emails it checks their
References or In-Reply-To in order to find matching Message-Ids and find
the reply's parent. Currently it is limited to Message-Ids matching the Odoo
pattern. However if an external email began a discussion thread, references
will not hold any odoo-like pattern.
Previously to commit 0028c42136 this was hidden due to a bug when
managing private messages. This code was also managing replies to external
emails due to a probably undesired side effect.
Correct way of checking if an incoming email is a reply to a thread is to
check that References or In-Reply-To Message-Ids match some stored Message-Ids
of mail.message. They don't have to match Odoo patterN
ir.needaction_mixin is not used anymore by the webclient.
From 9.0, the concept has changed: this feature is now
available in mail module, with the mail.thread mixin,
and message_neeadction field.
Remove all code handeling needaction bullet and
counter on ir.ui.menu, knowing that since 9.0
webclient does not display the counter anymore.
This code was, thus, useless and some RPC calls
were done for nothing, and adapt accounting
reconcialiation widget.
When uninstalling a module followers stay in the database because there is no
real link between ir.model and followers. Adding a m2o ensure followers are
correctly removed when uninstalling a module.
res_model fields is kept as a stored related field. This allows to keep
compatibility with almost all code using / searching on followers. Only
followers creation is changed a bit. As follower creation is done mainly
through a dedicated method few changes are required. Yey. Mat should be
happier now.
fix test
Old versions of Odoo did not correctly manage message_id of mail messages.
Thread formation was based on information present in References and/or in
In-Reply-To of replies to emails. Message-Ids could contain model and
res_id of a record. Thread formation was done using this information.
However commit 8253453d64 fixed that behavior
by correctly checking in existing mail_messages to find matching message-ids.
Message found was set as parent and thread formation was correctly done without
collision or possible issues with badly formatted Message-Ids.
A compatibility mode was introduced at the same time to handle previous versions
of Odoo. This commit removes this compatibility as it was done long enough
to ensure compatibility is not required anymore.
[TESTS] mail: tests updated, compat mode should raise in all cases now
When changing tracking mecanism in v9 'always' tracked fields lost their meaning.
They were managed like 'onchange' fields. This commit sets the old behavior back.
* 'onchange' fields are displayed in tracking every time they change
* 'always' fields are displayed in tracking every time they change or whenever
other tracking exist; those are used to display some contextual
information
If the 'To' of an incoming email is an alias on another model we now consider
this emails as a forward to a new alias. A use case for this is an email on
a task that should be considered as an issue and forwarded to another alias.
This commit remove required alias on res.users model. It also removes the
inheritance of mail.alias.mixin. The field alias_id is kept and allow people
to use aliases on users if they want. However there is no default void alias
created for each user anymore.
Default from of mail.message does not use user alias anymore. Indeed this
creates issues with aliases not being correctly configured and can be
confusing compared to private channels. Using user aliases is therefore
now done manually instead of being a default behavior.
Previous version of the test was actually not correct. Mailgateway was not
considering references as in-reply-to when trying to find answers that have
to be considered as a new thread instead of an answer to an existing thread.
Purpose of the test is actually to be sure that answers considered as a new
thread have no parent_id set. Otherwise you may have threads linked to
messages belonging to other records, leading to access right issues. Moreover
if this email begins a new discussion thread it makes no sense to have a
parent message set.
A new test is written to better simulate the test case. It sets a message_id
containing reply_to which is the way odoo uses to indicated that answers
to a message have to be considered as new threads. This is used notably in
mass mailing for example.
* mail_message.message_read() method is not used anymore since the chatter
refactoring in v9. message_format() is used instead. Tests for this method
are also removed, as they have no use anymore.
* mail_thread.message_set_read() is not used anymore. set_message_done is the
only method used by the new chatter as there is no read state anymore.
* removed an unused parameter in set_message_done, by the way
Convert YAML tests into Python tests:
- translation tests moved to test_translate.py
- test phases tests moved to test_phase.py
- safe_eval tests moved to test_base.py
- parent_store tests moved to test_base.py
- float rounding tests moved to test_float.py
- `ir.rule` tests moved to test_acl.py
- search tests moved to test_expression.py
- The "From" should not be the administrator user but
the postmaster/system, and should be an address that
ignores double-bounces. Using the default bounce
email accomplishes both.
- The "To" recipient should be the "envelope from"
sender when available, usually as provided by
the "Return-Path" header set by the upstream MTA.
If not present, fall back to the "From" of
the original email.
- adapt tests to verify the behavior wrt Return-Path
Finally add support of CIDs in incoming emails. Inline images are recognized
and added as attachments. Image links are updated from src=cid: to src=link
using the /web/image controller.
It has been decided to keep the image in atttachments instead of putting them
in base64, like proposed in various PRs. Indeed we prefer to store this data
into the attachments instead of directly putting it in the mail_message table.
Moreover this enable the display of attachments in the chatter and record views.
Quote detection is now done in the sanitizer itself. It tags nodes that are
inside quotes (signature, text quotes, email quotes). The purpose is to remove
html_email_clean and have all the html cleaning / sanitizing inside a single
function. When a node is tagged, data-o-mail-quote is set on the node.
This attribute is added in the whitelist of valid attributes for the
sanitizer.
[REM] Support of shortening messages. The read more / read less will only
display or hide detected quotes and signatures. Shortening messages above
a given amount of characters is not supported anymore. Indeed it adds much
complexity to the sanitizer without adding much value to the result. The
primary purpose of the sanitizer is indeed to remove noise and unnecessary
content.
[TESTS] a lot of test are not necessary anymore, as read more / read less
display will be moved in the front-end and as the shortening has been
removed.Tests have therefore been cleaned and simplified.
[DEMO] mail: small demo update to include a bit quote detection
Mailing lists (mail.channel) should not send specific notification emails.
Indeed there can be a lot of recipients and customizing each email can
take time to compute. This leads to posting a message on a mail.channel
being very slow.
It is now possible for a model to customize the notification email
recipients computation. The first use is to ensure that mail.channel
encodes recipients using email_to instead of recipients_ids. This way
less processing is performed on notification emails.
This is a manual cherry-pick of commit d4a1eb4435
that was not forard ported. Mail has indeed evolved since 8.0 and its
forward port was not an easy task.
This commit also includes the fix of mail.channel recipients. All are now
considered as equal and receive a simple notification email. No distinction
is done between partners and users. The notification emails for channels
should be as simple as possible.
When sending a mail.mail with email_to, the processing split the email_to into
a list of addresses. However if the found addresses use the form name <email>
the name if lost in the process. A new email_split_and_format method is introduced
in tools and used to avoid loosing that information.
Mailing lists (mail.group) should not send specific notification emails.
Indeed there can be a lot of recipients and customizing each email can
take time to compute. This leads to posting a message on a mail.group
being very slow.
It is now possible for a model to customize the notification email
recipients computation. The first use is to ensure that mail.group
encodes recipients using email_to instead of recipients_ids. This way
less processing is performed on notification emails.
Use convert_to_cache and convert_to_read to format onchange values.
Fix: default value can be a command list, the onchange convert the comand list into a wrong comand list of command list.
Create `message_post_with_template` helper method to factorize the simulation of a mail.compose.message wizard.
Also, fix the generated attachments of mail.compose.message wizard by returning ORM command (6, 0, ids) instead of the list of attachments ids. In order to standardize the behavior of the wizard, and since the ORM support command assignation in onchange api.v8, all the x2many fields of the wizard return a command.
FYI, that was tde's idea !
mail.channel doesn't have the normal behavior of mail.thread,
but the test are based on mail.channel (which is thus a not so good idea).
res.partner is the other model available in mail module, implementing
the correct behavior of mail.thread, but trigger AccessError. The tests
are commented from now, since TDE and I rewrite the test with a complete
module dedicated to the test and implementing the expected behavior of a mail.thread.
Notification emails have been redesigned. They notably include buttons
allowing to perform some action directly from the email.
The notification creation and sending has been partially rewritten
and improved. The purpose is to lessen the number of rendering to perform
when sending emails to recipients. Recipients are first categorized into
groups. Basic groups are partners and users. The notification template
is then rendered twice, one for followers and one for not-followers. In most
cases there will be few rendering to perform. Through inheritance it
is possible to further categorize users. For example HR users / officers
that have approve / refuse buttons in their email.
A custom data structure is used to store data about buttons and actions.
URLs, follow / unfollow are added in the structure and used in the
template to render the email for a given group.
New routes are added in mail. Those allow to perform some action, like
going to a form in create mode, following / unfollowing, executing a method,
sending a signal for a workflow. Those routes are for users only and rely
on classic access rights.
A generic route for viewing records is added. It replaces the old redirect
action. According to some specific action given by the already-existing
get_access_action, the record will be visible for everybody (forum, blog)
or restricted (going on the Inbox / login / form view, according to access
rights).
The next commit will add the various inherits necessary to add the actions
in the main addons.
Replace deprecate controllers like /web/binary/image, /web/binary/saveas...
Use ETag for all content with 'unique' option to cache the content if the content is never changed.
Main changes :
- mail.notification model is removed. People do not receive notifications
anymore. Instead two ways of following documents exist
- using a channel; messages will be displayed on the channel itself
in a near future commit
- following with its partner; messages will all be considered as
needaction, using a new m2m table. People should receive less
needaction messages by following less records by themselves.
There is no more read / unread state anymore. Instead only needaction
messages are considered. Todo (Favorites) messages still exist, and are
stores on a new m2m table instead of using decorated notifciations.
- the main filter for documents is not message_unread anymore, but
message_needaction. A lot of views and filters have been updated
accordingly.
- the vote feature has been removed
Some features from live_chat have been moved to the mail module :
- channels now have members, replacing followers;
- a decorated m2m is used to link channels and members. It stores the last
seen message on the channel for a specific partner;
- channels do not create menu entries anymore, because the
NewChatter will have its own display and use of channels;
- access rights have been updated accordingly, using members instead of
followers
Followers can now be partners or channels. Partners following a document
will receive needaction, as previously. However people can follow documents
through channels. Members of a channel are able to listen to a stream
of messages using the channel. Those messages do not create needaction
messages. It is therefore possible to follow documents without receiving
too much notifications. For interesting documents subscribing with its
partner will create notification.
message_follower_ids fields is udpated. It is now a many2many to
mail.followers, not to res.partner anymore. A subscription can be either
a partner (partner_id) or a channel (channel_id).
Some access rules have been updated accordingly.
Thibault Delavallée