Rev. 15174e9a70 explicitly
cached ir.ui.menu entries, and required an explicit
cache invalidation when users changed their mail.group
subscriptions (mail.group used to override the ir.ui.menu
search(), cfr e.g. 89e404301b)
The menu search() override is gone as of 9.0, so it's time we get
rid of the unnecessary cache invalidation.
When posting a comment after an answer in the forum, a mail
was sent to each subscriber with 'Re: False' as title.
In fact the title has to be 'Re:' + the name of the parent
record of this message.
When a mail is sent from the post, a link to access the subject
of the forum must be included in the mail.
opw:679073
When posting a comment after an answer in the forum, a mail
was sent to each subscriber with 'Re: False' as title.
In fact the title has to be 'Re:' + the name of the parent
record of this message.
When a mail is sent from the post, a link to access the subject
of the forum must be included in the mail.
opw:679073
When tracking value is converted to be rendered as a message_post, we convert
the date/datetime with the current local from momentjs.
Related to #12327
Courtesy of @aab-odoo for help and review.
The button "Convert to opportunity" in the mail notifications
sent when posting a message on an opportunity just coudln't
work as it attempted to call the `convert_opportunity`
method without one of its required method parameter.
opw-680017
When tracking value is converted to be rendered as a message_post, we convert
the date/datetime with the current local from momentjs.
Related to #12327
Courtesy of @aab-odoo for help and review.
When posting on a thread the user can be auto-subscribed to its default
types. But if the user has previously been subscribed to other subtypes,
those are lost.
With this commit, user mentionned (@{username} in message) or added as
follower for default subtypes are not subscribed if they were already
followers of the record.
So if default subtype is "Comment" and user was only following subtype
"Alarma!" (by checking it and then un-checking "Comment"), then if the
user comment:
-> before this commit, the user would then follow subtype "Comment" and
not follow anymore "Alarma!"
-> after this commit, the user would follow the subtype "Alarma!"
closes#12008
opw-669127
opw-673766
Otherwise it is not visible when set on an instance of the new API.
self is a recordset instead of the model `res.users`
Without this patch a low priviledge user was not able to modify its own value
of `notify_email` through the preference window.
available in channels and chats, but not livechats as the public user isn't
really "in" the channel (the command would reply that you are alone in the
channel, which isn't necessarily the case)
Use the mention mechanism of the composer to autocomplete on canned responses
(keyword :) with fuzzy search.
Directly perform the string replacement in the composer, instead of
server-side as before.
Add a menu item to access an editable list view to create and edit canned
responses.
Add two canned responses as demo data.
Rev. 56cec604e6 modifies
the auto-commit behavior of the mail queue scheduler,
to allow using it within tests.
The condition was wrong and always True as soon as
the registry was loaded, permanently disabling
auto-commit, both during tests and outside tests.
This broke the duplicate emails protection.
When a user is subscribed to a channel with many messages,
the discuss initial rpc /mail/client_action can become very
slow (in production, the rpc took > 20s when subscribed to
the Community mailing list). This is due to the query in
_get_message_unread, counting the number of unread messages.
This commit adds an index on the relation mail_channel_partner,
this allows postgres to perform only index lookups, and speeds
up the query by 2 order of magnitudes.
Avoid raising an access denied error for messages that
the user has indeed be notified about.
The issue arose when a message posted on a document inaccessible
to the user was notified to one of the channels the user
is subscribed to.
The access control logic on messages relies on 2 heuristics
to grant read access to a message:
a. either the user was notified about the messages, by being
a follower of the document, or a subscriber of a channel
following the document (in that case the user can see the
message but not the document)
b. or the user has read access to the document on which the
message is posted (in that case the user can see both
the message and the document)
Case `a.` sometimes fail to match when a message got notified
to several channels including one the user was not subscribed
to. Depending on the order of the returned rows in the SQL
query, the "foreign" channels could shadow the channels of
the user, making `a.` a non-match.
If case `b.` did not match either, the user would have the
`read` access denied, even though the message was visible by
the `search()` method.
The fix explicitly makes case `a.` match if the user was
notified in *at least* one channel.
This was not done through a change of the SQL query ORDER,
for readability reasons.
- 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
The possibility to choose a subtype when logging a note was added with the
activities mechanism in CRM. However as the user should not use the chatter
but a dedicated wizard in order to do this, the dropdown is removed.
The internal subtype mechanism is kept. Only the possibility to log something
else than a note through the chatter UI has been removed.
By default, users are supposed to be able to write messages
in threads only if they have the write access on the record.
This behavior is the behavior defined in Odoo 8.0.
This behavior can be changed by defining
`_mail_post_access` on the model,
to allow the creation of new messages
if the user has only the read access, for instance.
This is the case on `project.issue`, for instance.
Since 9.0, @ revision 88b8cd0587,
this behavior was broken: Any users having the read
access on the record was allowed to write messages in the thread,
while this should not be the case, except if
`_mail_post_access = 'read'`
has been defined on the model.
This is because the SQL query which is performed in order
to know the thread messages the user has been notified of
was expected to return only the ids of the notified message,
while it actually always returned all the message ids of the thread,
because of the LEFT JOINS, e.g.
```
LEFT JOIN "mail_message_res_partner_rel" partner_rel
ON partner_rel.mail_message_id = m.id AND partner_rel.res_partner_id = (%%s)
```
Instead of just checking the ids of the messages returned by this
query, it must check that one of the two columns
`partner_rel.res_partner_id` or `channel_partner.partner_id`
is filled, meaning the partner has been notified of the message or
is a member of the channel the message has been posted to.
opw-668589
Otherwise recomputation may fail with "record does not exist or has been
deleted" when creating records with a value directly set for e.g.
'image_mediun' on a new product.
The issue comes from the storage of the images. When creating a product, the
creation of an attachment for storing the field `image_medium` triggers the
recomputation of that field before its dependency `image` is set. As `image`
is initially null, `image_medium` is recomputed as null, and this deletes the
attachment just created before the latter has completed its creation! As a
consequence, some code at the end of `create` for the attachment crashes
because the record has been deleted.
The following models have been fixed: `fleet.vehicle.model.brand`,
`hr.employee`, `im_livechat.channel`, `mail.channel`, `payment.acquirer`,
`pos.category`, `product.template`, `product.public.category`, `res.partner`.
opw 666330
Closes#11516
Martin Trigaux