Purpose
=======
Currently fields with a `groups` attribute can't be tracked.
Otherwise changes would be visible by all in the chatter, including
users which normally don't have the access rights because they are
not members of `groups`.
Specification
=============
Filter tracking field values according to the `groups` attributes.
Users without the access rights should not see them.
If a message is only composed of tracking values and the user doesn't
have the rights to see them, an empty message should not be displayed.
`channel_info` can be called on multiple channels especially during
the init_messaging. The current implementation will perform read and
other queries in the loop. This commits aims to refactor `channel_info`
in order to read all informations in database out of the loop.
Computation of members informations is now the same as for `direct_partner`
As a side effect direct partner will have an email adress and members will have
im_status and out_of_office message if the partner is in a
channel of type chat. It would be easier to compute im_status in all case but
this could create performances issues when calling channel info on channel with
hundreds of users.
channel_fetch_preview will make a query in database in any case but seems to work ok
in api multi. We can put it out of the loop.
44ac7903cc fix shouldn't be broken by this refactoring since we are no longer using the many2many to find direct_partners.
This commit is a refactoring of im_status management.
This commit also add im_status in two places, near the author in a mail thread and on each suggestion when using mentions.
A service to manage im_status will have multiple benefits here:
-centralise information, avoid to call the server multiple time for the same im_status
-update all im_status at once and keep consistency in display.
With this commit, the im_status updates are now done by rpc call.
Updates where previously made with the bus but this has some drawback,
since the bus will only give the information 50 seconds after the beginning of
the request, in the worst case, we van wait 2*50 seconds to get an update.
More than that, the im_status where only updates for pinned dm_chat. Dm chat
are synchronized cross tabs, making the use of the bus possible for this purpose.
Since we will need to display im_status not linked to dm_chat, the list to update
will be different from tab to tab making the use of bus difficult for this purpose.
Technical notes:
-im_search has been moved from bus to mail addons since it concerns mail.channel
-Update of an im_status should be reflected everywhere in the page.
Since im_status is a rendered template used in multiple widget, we should add
the correct logic to all concerened widget. The current solution is simple:
use a jquery selector to find every place where im_status is rendered.
-we add a new im_status: im_partner. This will indicate that that
the partner has no user linked to him, making it possible to avoid to ask
for status updates for this partner.
-The update will only be done when the tab is focused. (and will be done
asap once the tab get focus back)
Before this commit, when creating a partner automatically when creating
a message with a template, the company on the partner was wrongly set
After this commit, we try to retrieve the company from the model on the template
OPW 1934392
closesodoo/odoo#30893
When uninstalling a module, the messages linked to the records
of that module are not deleted leading to ghost messages when
reinstalling the module.
This is due to the lack of foreign keys in the definition of the
chatter making it impossible to cascade delete.
opw-1928208
closesodoo/odoo#30798
Purpose of the task is to improve the usability of activity types and
activity scheduling.
Another purpose is alto to protect some master data activity types by flagging
them and preventing their deletion.
Containing
* make the activity type as master data so deletion will be prevented;
* improve the usability of the activity type;
* prevent the deletion of activity type which are used for automated activity;
* change the usability of activity scheduling modal;
This commit is linked to task ID 1907970 and PR #29257.
To reproduce:
1) Enable multi-company
2) Create two companies: c1, c2
3) Create two users: bob in c1 and alice in c2
4) Install subscription
5) Remove the ir.rule that forbid users from accessing subscriptions
made in other companies: "Subscription multi-company"
6) Using u1, create a new subscription in c1
7) Using u2, follow the chatter of the newly created subscription
allowing the user to post messages/log notes.
8) Using u2, send a message with an attachment. Access Error.
The problem raises only for the **first** attachment. That
attchement is written on the record as the main attachment thus
raises an error if the user doesn't have write access.
There is no problem to add attachment to any following record or
when the user has write access on the model. If the user doesn't
have access to the chatter, he is blocked before accessing the
write thus it is safe to sudo it.
opw-1915606
closesodoo/odoo#30659
- Debug mode,
- Add multi-company to admin (user id 2),
- Create new company (company 2)
- Activate res.partner multi-company record rule
- Create invoice
- with first company (the default one)
- with a customer having an email address that doesn't exist
- Send a message in the thread, making sure the customer is in the
follower
- Wait for the message to bounce (red mail icon in the thread on the
given message).
- Change user to company 2 (in the dropdown menu next to the user
dropdown menu in the upper right corner)
- Refresh, access error, even in the app switcher.
This is because Odoo tries to display in the notifications the email
that failed, and crashes because the user doesn't have access to the
partner of the email.
We filter out the notifications related to objects that the user doesn't
have access to.
opw-1924359
closesodoo/odoo#30348
As `formataddr` only accept strings as arguments, an exception was
raised when trying to notify a mailing list channel with followers
without email.
closesodoo/odoo#30492
Before this commit, when livechat operators had chats in the
Discuss app and reload their page, they could loose some
pinned livechats.
This problem only occurred on livechat conversations when both
users are authenticated. Any two-user channels should always
be pinned by default, which is the case for internal chats.
This logic was applied on channels with type `chat`, but this
is ignored with livechats because they are channels of type
`livechat`.
This commit fixes the issue by defining internal chats and
livechats as `chat`. Any chat conversations are automatically
pinned when a message is posted, including livechats.
Note that before this commit, the livechats were visually
pinned in the Discuss app, although the server did not consider
them as pinned. The client-side code always assume conversations
are pinned, which is why a page refresh looks like a loose of
previously pinned conversations.
opw-1919327
closesodoo/odoo#30200
- Create a PO for a French customer
- Send by email
The body of the email is in French, but some parts (such as the View
button or the footer) are not translated.
The body is translated following the field `lang` of the email template,
in this case `${object.partner_id.lang}`. This is done when opening the
mail composer (so the message appears in French). However, other parts
are rendered only when sending: at this point, the language to be used
in the template is lost forever in the darkness.
To avoid this, we keep a specific context key `custom_layout_lang` that
we retrieve when rendering the custom layout.
opw-1908420
Do not use the model `_description` field which cannot be translated. Use
the `display_name` of the corresponding model instead.
Moreover, `<t t-esc="'%s' % model_description or 'document'"/>` gives
`'None'`, while `'document'` is expected.
This adds a query to some tests, which is expected since `display_name`
requires information stored in the DB, while `_description` is defined
at the Python level.
opw-1908420
This commit adds the seen icon next to a message for all channels
except livechat.
It tracks received and seen messages for all members of the channel.
Icon is either 1 or 2 check(s) ('v' or 'vv').
Those are the different states of this 'seen' icon:
ICON: DESCRIPTION:
no check .................. no one has received the message.
1 check ................... some members have received the
message, no one has seen it.
2 checks (greyed-out) ..... some members have seen the message,
some or everyone has received it
2 checks (green) .......... all members have seen the message
This icon is not shown for messages preceding the last message seen
by everyone, in order to reduce visual noise.
Task-ID 1881001
This commit adds the possibility to customize the name
of a DM conversation. To do so, click on the gear icon
when hovering on a DM in the discuss sidebar.
This feature intentionally removes the access to the
settings of a DM, because the settings view only makes
sense for non-DM conversations.
Task-ID 1881001
Before this commit, when accessing a channel after a page reload,
the list of members in a channel was not known until the composer
on this channel has the focus, either in the Discuss app or in a
chat window.
This was a good-enough condition when information about members
was limited to mention suggestions, which requires having the
focus on the composer. However, with the 'is typing' features
on channels, it requires being aware of the members of the channel
at the moment of the rendering in discuss or in a chat window.
This commit fixes the issue by providing the list of channel
members when retrieving information about the channel.
Without this fix, the 'is typing' notifications could sometimes
not determine the name(s) and email(s) of user(s) typing something.
Revision on https://github.com/odoo/odoo/commit/cd34f6de727d5b3858420cff3c9d3c5995c4e75c
Before this commit, when receiving a new message from a new DM
or livechat, the newly opened chat window was automatically
focused and marking messages as read.
Chat windows that are automatically opened without any user
interaction, such as when receiving a new message from a chat,
should not be focused. Those chat windows are "passive", and
the user must click on them in order to have focus and mark
messages as read (the chat window is no longer passive as a
result). The bug has been introduced by the refactoring from
the commit above.
In fact, there was a very short period of time during which the
chat window was passive. However, due to the way chat window
server-side state synchronization works, the chat window was
automatically closed then re-opened. This resulted in some visual
flickering of the chat window ('open' > 'close' > 'open'), and
the conversation was automatically marked as read. This was a
consequence of the actions 'open' > 'close' > 'open' that removed
the passive property of the chat window.
Chat window server-side synchronization relies on a notification
that tells the state of the conversation. Due to bad design, this
notification had exactly the same format as the one for notifying
all browser tabs of a newly joined conversation.
This commit fixes the issue by distinguishing "channel join"
and "chat window state" notification, so that the former is not
treated as a chat window notification. It fixes the problem
because it was precisely the "channel join" notification that caused
the chat window to close and loose its passive property.
Task-ID 1914735
opw-1914371
closesodoo/odoo#29223
The signature is shown by default when sending a mail and in particular
case it is not shown.
In c8d283a592 there was a small regression that in some instance the
signature that was shown before is not shown anymore. This is because
the default in those instance is to not show signature.
eg. a message sent in a chatter would not have signature in sent emails
With this commit, the previous behavior is reintroduced.
opw-1903001
opw-1896262
closes#29088
When a new user is subscribed to a channel, (multi-user, without emails)
a message is posted on this channel.
The mechanic used for that is unfortunately not very reliable
Javascript will call channel_join_and_get_info every time a channel
is added (client side) even if the user is already in the channel.
This fix simply check that the action_follow actually add the
user to the channel before sending the message.
We should avoid to call channel_join_and_get_info in this case and only call
channel_info but this fix will temporary fix the issue.
closesodoo/odoo#29441
Getting systray activities for custom models (i.e. created with Studio) crashed.
If it's a custom model, its `_original_module` attribute is not correctly set so
trying to retrieve the icon based on this attribute does not work.
When a user/partner is deleted, their messages lose their author.
Replying to those may result in a failure to fetch the mails from the
incomming mail server.
without this commit, partner_ids == [(4, False)] and this value "goes
down" all the way to the orm method "write" of the Many2many field.
resulting in a SQL query like :
INSERT INTO mail_message_res_partner_rel (mail_message_id, res_partner_id)
(SELECT a, b FROM unnest(ARRAY[149855]) AS a, unnest(ARRAY[false]) AS b)
EXCEPT (SELECT mail_message_id, res_partner_id FROM mail_message_res_partner_rel WHERE mail_message_id IN (149855))
which fails with the ProgrammingError : EXCEPT types boolean and integer
cannot be matched
opw-1921805
closesodoo/odoo#30528
Suppose that a Task is added on a task via a studio customisation.
Then the _get_message_needaction method gets called on the onchange of the
toplevel task, which triggers another call to _get_message_needaction.
During that update, we get a self with a model.newID; its ids field is empty,
so the list of tasks res itself is empty.
As a result the method crashes on a malformed query.
This can in turn prevent the completion of some higher-level operation,
e.g. a state change on the task.
opw 1909043
closesodoo/odoo#29084
Blacklist was added to mail.channel.partner in order to avoid sending
mail notification for a channel in send mail mode if the partner was
blacklisted.
But as everythin is done using directly the res partner model, this
inheritance is completelly useless.
Moreover, since introduction of mail.address.mixin with email_normalization
(inherited by blacklist.mixin), the partner_email cannot be normalized as it
is a non stored related field. The computation of email_normalized will
fail.
Task ID : 1911716
Closes PR #28922
This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
Alexandre Kühn