| Age | Commit message (Collapse) | Author |
|---|
|
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closes odoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
|
|
*bus,mail
This commit extracts the common basis of the env to use both in
the frontend and the backend. The public env now contains most of
the features that were previously (only) in the webclient env.
Moreover, the PublicRoot no longer uses the ServiceProviderMixin,
such that services are only deployed once, in the (public) env.
Owl components can now be defined in the website, and rely on a
properly built env. Legacy widgets still works as they access
services through the PublicRoot (via trigger_up) which redirects
those requests to the env.
|
|
fixes #45425
closes odoo/odoo#51717
X-original-commit: a210d68af04490c0daa535e3151ed5edbd431898
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
|
|
The purpose is to have more common code for failure and notifications, with less
override in `sms` and `snailmail`.
task-2176017
closes odoo/odoo#44170
Related: odoo/enterprise#9140
Related: odoo/upgrade#918
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
|
|
Revision on https://github.com/odoo/odoo/commit/8e5b6ab02aa95c204ea7bd241e6b8944d5972d43
Intent of commit above was to remove server-side synchronization of
chat windows in mobile. To do so, it prevented sending RPCs for chat
window state in mobile, in addition to not automatically adapt state
of chat windows in mobile from longpolling notification.
This implementation, while functionally working as intended, had
disturbing intermediate logic that could potentially lead to bugs
in the future. Specifically, on mobile, new channel did not directly
trigger a re-render of discuss widgets. However, and thankfully, the
related new message was triggering the rendering, so that UI
correctly has channel and its notification.
This commit simply improves code so that new channel always triggers
a rendering, even in mobile, like before the commit above. Of course,
to preserve the intent of not synchronizing chat windows in mobile,
new detached channels must still not auto-open a chat window, and
this commit clarifies this intended behaviour in the code.
X-original-commit: 1046d063ca46aacb1e186599b5d4a02ef9c8e18d
|
|
Before this commit, when receiving a needaction message while messaging
was not ready (i.e. `/mail/init_messaging` not resolved), the web client
crashed with the following error message:
```
TypeError: Cannot read property 'incrementMailboxCounter' of undefined
```
This happens due to reception of needaction message incrementing counter
of mailbox Inbox, but this mailbox is only added after messaging is ready.
This commit fixes the issue by directly adding inbox mailbox on starting
the mail service.
closes odoo/odoo#45442
X-original-commit: 741acb9f48f2d3542549791a8fd7d6fb318bc862
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
|
|
Currently when you open, for example, 5 chat windows on the desktop,
each of those windows will be opened on mobile as well.
The big issue with that is that I have to shut down all windows before
starting to work on the application.
To make things simple, you have to explicitly open chat window to
make it appears on mobile. Synchronization is blocked in both direction.
We don't update the chat window state on the server and we no longer
consider notifications (bus) about it.
Tests were added in enterprise.
Task ID: 1891952
closes odoo/odoo#41052
Related: odoo/enterprise#6943
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
Before this commit, when clicking on "Unstar All" from Discuss
'Starred' mailbox, it crashes with following error:
```
TypeError: unstar_all() takes 1 positional argument but 2 were given
```
This commit fixes this issue
closes #37994
closes odoo/odoo#38738
X-original-commit: ec330d1668640d3ae75e23a70695006a63dbe217
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
|
|
closes odoo/odoo#37372
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
Before this commit, discuss widgets had to wait for the route
`mail/init_messaging`. This behaviour slowed down the loading of the
web client.
This commit solves the issue by rendering discuss widgets even when
`mail/init_messaging` hasn't been resolved. For instance, the
messaging menu displays a spinner until messaging becomes ready.
Task-Id 2072835
closes odoo/odoo#37031
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
|
|
Before this commit, when a user received a needaction notification
on a message already stored locally, it crashed with this error:
`TypeError: Cannot read property 'getThreadIDs' of undefined`
This is caused by `addMessage` returning a Promise not resolved with
the message when the message is not new. The returned promise should
always be resolved with the message, in order to be consistent.
closes odoo/odoo#35724
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
|
|
|
|
This commit adds a new mailbox in the Discuss app called 'History'.
Messages that have been marked as read are moved to 'History'.
Notifications are required to link history messages to users. So
notifications are now deleted after they are more tha 6 months old.
This means History mailbox keeps less than 6 months old messages.
Note that this feature only works when user notifications are handled
in Odoo. This can be set in the user preferences, under the
"Notification Management" section.
Task-ID 402597
|
|
closes odoo/odoo#34747
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
Before this commit, if we had a livechat channel with a user and:
- in backend use command "/leave" to leave and unpin conversation
- [do not reload the page (or there is no issue)]
- then the user sends a new message
The chat window opens just with the new message. Fetched previous
messages are ignored due to being already in the mail manager, and
links between these messages and the threads were never updated.
With this commit, when fetching messages that are already in the mail
manager, these messages are linked again to threads.
This commit also fixes an issue in which messages moderated with
status "accepted" were not correctly removed from the moderation
mailbox. This problem occurred after the fix on re-linking messages
to threads.
opw-2031270
closes #34761
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
|
|
|
|
closes odoo/odoo#34850
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closes odoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
Before this commit, the `author_id` of a message with odoobot was
`"ODOOBOT"`. This leads to some issues due to `author_id` being
considered as an array `[partnerID, name]`.
Because of this, mail status manager was registering a partner with
ID `"O"` (1st char of `"ODOOBOT"`) for fetching its `im_status`. Its
`im_status` was never updated, since no partner has such ID. However,
the mail status manager kept this partner flagged with missing
`im_status` and still attempted to fetch its `im_status`,
indefinitely.
This commit fixes the issue by turning `author_id` of a message with
odoobot into arrray `["ODOOBOT", "ODOOBOT"]`. That way, `author_id`
of a message is always an array, and the `im_status` of `"ODOOBOT"`
is no longer fetched.
|
|
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
Revision on https://github.com/odoo/odoo/commit/844fb2b51ea7cfa557b19466c0a53dde19433e7a
The commit above added the seen icon on messages in a channel.
However, since this feature, there was a performance issue
when opening the systray messaging menu with several pinned
channels: lots of RPCs are made, almost 1 for each preview
in the messaging menu.
The RPCs comes from the reception of the last message in the
channel, to let the current user notify that he has received
the messages in the channel.
Those RPCs were made for each channel, thus the more pinned
channels the more RPCs were made when opening the messaging
menu.
This commit fixes the issue by throttling and batching the RPCs.
To do so, instead of letting the channel model handle the RPC
`channel_fetched`, the mail service now handles it. This has
the advantage to throttle the RPC globally and to batch the
requests to notify that messages have been received on channels.
closes odoo/odoo#31026
|
|
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)
|
|
- added unaccent search on POS customer/partner and product
- moved unaccent from "mail.utils" to "web.utils"
- added more character to make function accurate
We might use str.normalize(from ES6) but the problem is str.normalize method can not consider some double characters i.e. accented character when normalized it returns 2 normal characters and normalize method returns single character, so here custom unaccent method is used to normalize the string
What we can improve here: We can use str.normalize method and check if string is still have unaccented charaters that we can call our unaccent method but this unaccent method is also working and performing well
closes odoo/odoo#27671
|
|
We want to add new kinds of failures to the list in the systray, such as Snailmail or SMS failures.
Until now, failures linked to documents of the same model were grouped together in the systray.
Different types of failures should not be grouped in a single line so we add a '_failureType' variable to mailFailures and group them only if their type is the same.
closes odoo/odoo#29855
|
|
This commit fixes two related issues:
1. Previews without any message should not be dated.
Before this commit, when a channel or dm preview had no date,
it was displaying the current date. This commit fixes the issue
by not showing the date for those previews.
2. Dates previews should appear before undated previews.
Before this commit, undated previews were considered similarly
as dated previews in the ordering of previews in the messaging
menu. Since DMs are shown before Channels, any pinned DM without
any message were displayed on top of messages with some message.
This commit fixes the issue by putting undated previews after
dated ones. This rule is applied before considering type of the
thread (i.e. DMs before channels).
Task-ID 1912001
|
|
Revision on https://github.com/odoo/odoo/commit/cd34f6de727d5b3858420cff3c9d3c5995c4e75c
Resulting of the mail JS refactoring, the list of prefetched suggestions
has been changed as follow:
- before: list of list of mention suggestions `{Array<Object[]>}`
- after: list of mention suggestions `{Object[]}`
The change resulted in wrongly thinking that wrapping the list of
suggestions in a list was pointless, thus simplifying it as a simple
list of mention suggestions.
However, because of this change, it has become much harder to
mention employees and followers of documents from the chatter:
it now always fetches all partner suggestions at all time, whereas
before it was suggesting followers, then employees, and finally all
partners based on the input of the user.
In fact, there was a purpose of using a list of list of prefetched
mention suggestions, which is to group suggestions by "priority":
followers first, then employees, and all partners as a last resort.
This commit re-introduces prefetched mention suggestions as a list
of list of partners, so that it re-becomes easier to mention
followers and partners of a document from the chatter.
Task-ID 1910111
|
|
This commit makes small improvements on the messaging menu with
the new module `mail_bot`:
[IMP] When OdooBot has a request, it now adds "+1" to the counter of
the messaging menu. The related preview also has a bold title,
and displays "(1)" next to the title.
[REF] Static previews are no longer in mail_service. This was only
used for "OdooBot has a request" preview. This logic has now
been moved to the module `mail_bot` (was previously in `mail`).
[FIX] Title of response of push notifications permission clearly
states whether permission has been granted or denied
(was displaying "[Object object]" before this commit).
Task-ID 1877502
|
|
Since the title of a notification is in a t-esc, the style wont be applied
|
|
|
|
1. Odoobot shouldn't talk to admin when demo data are installed
Odoobot will talk to a user on it's first connection, meaning that
a dev will see this chat window a lot. The state disabled is not a
real state but is explicit, the odoobot wont be initialized in this
case. It is still possible to test odoobot flow with demo user.
2. remove old odoobot image and update link
3. small improvements in odoobot answers
|
|
In f2302df dm type of channel was renamed to dm_chat, this commit takes
this into account in other part of the code.
|
|
Before this commit, when we received a new message, the counter was correctly
updated, but not the last message in the messaging menu preview.
This is due to making changes to the counter before adding the message in the
thread. When there is a change in the unread counter of a thread, it warns its
views. The messaging menu renders the previews of each threads in the preview
items, using in particular the last message in the thread.
This commit fixes the issue by making changes on the unread counter of a thread
after the message has been added to the thread.
|
|
This commit makes a lot of small improvements of the JS of mail and
related modules.
A. Mail Manager
---------------
im_support:
- [REF] Slightly more robust way to determine a support
message, so that it more reliably falls back on
default kind of message (i.e. support channel UUID
should be clearly set).
mail:
- [REF] Improved method names for readability purposes.
Some examples:
- `fetchFromServer` becomes `fetchMailStateFromServer`
- `_initialize{*}` becomes `_update{*}FromServer`
- `_isModerator` becomes `_isMyselfModerator`
- [REF] Use 'template' pattern design to make Include on
Mail Manager much more robust. In particular,
the flow is always as follow:
1. Initialize internal state.
2. Listen on buses.
3. Fetch mail data from server.
- [REF] Improved workflow for thread window workflow
(Shorter & more readable).
B. Mail Tests
-------------
- [REF] Thread Window Tests crashes with clean message when
there are some thread windows open before running the
tests.
C. (Model) Message
------------------
- [REF] Improved method names for readability purposes
(e.g. `isAuthor` becomes `isMyselfAuthor`).
D. (Model) Thread
-----------------
- [REF] Improved `init` parameters on each kind of thread.
- [REF] 'Thread With Cache' has been renamed to 'Searchable
Thread': it embraces all kinds of threads that can
be used with the search view.
- [REF] 'DM' has been renamed to 'DM Chat' (for clarity).
- [IMP] New Livechat model in the backend.
- [REF] No more direct instances of the Channel class: public
and private channels are now 'Multi-User' channels,
while DM Chat and Livechat are 'Two-User' channels:
This change has been made so that instances of classes
always have direct classes as "leaf" in the Class
modeling. It eases making changes to a certain model
without being too constrained by another model.
- [REF] As a consequence of above changed, the method `isChat`
has been renamed to `isTwoUserThread`.
This is to avoid confusion with the terminology
'chat', which is more like a shortcut for 'quick real-
time conversation'. In other words, the property of
'chat' depends of the way to interact on a thread, not
of the intrinsic type of the thread.
Still, some parts have kept the terminology 'chat',
such as in the systray messagin menu.
- [IMP] Added `message_added` and `message_posted` hooks,
which may be useful to easily hook on those events.
E. Thread Widget
----------------
- [REF] Now uses a `mail.model.AbstractThread` for the
rendering of a thread, instead of a list of
`{mail.model.AbstractMessage}`.
- [FIX] Stick thread scroll height to bottom on new rendering,
if it was previously at the bottom of the thread.
- [REF] Option ORDER has its meaning changed: it now refers
to the chronological order of messages in the thread,
in which DESC means 'from top to bottom', while ASC
means 'from bottom to top'.
- [REF] Improved doc on templates, in particular with the
option `ORDER`.
F. Thread Window
----------------
- [REF] Moved more logic to thread windows, which were
previously in Mail Window Manager.
- [REF] Now hides the thread widget attribute. So instead of
`threadWindow.threadWidget.isAtBottom()`, it uses
`threadWindow.isAtBottom()`.
- [FIX] New received messages when not having focus on Odoo
tab should always make the corresponding thread
windows "passive" (i.e. windows that keep threads
unread until click on them).
- [FIX] Blank thread window (i.e. 'New message' TW) correctly
opens Discuss with 'Inbox' when clicking on 'Expand'
Button in the title
- [FIX] Do not display the composer for channels with property
'mass-mailing' set in thread windows.
G. (Website) Livechat
---------------------
- [REF] Some `trigger` have been turned into `trigger_up`.
- [REF] Some logic has been moved to models (e.g.
`{im_livechat.model.WebsiteLivechat}`), from
`{im_livechat.im_livechat.LivechatButton}`.
- [FIX] New messages should be received in real-time. The
longpolling was broken with a recent refactoring on
bus service (6448420c5dd160470e465dee7729d19d8d5e7bab).
|
|
Purpose of this commit is to improve the onboarding and the first steps of
Odoo notably when using Discuss and inviting first people to join Odoo.
In this commit we now ask the user to activate desktop notifications. Like
already done in Discuss a message will appear in systray in order to ask the
user to do it. This message will disappear once the user accepts or blocks
desktop notifications.
This commit is linked to task ID 1838588 and PR #25075.
|
|
The purpose of this change is to make the code clearer and testable.
In this change, the 'tab_manager' static object was merged with the bus
cross tab.
Cleaning was done to clearly define private and public functions as well
as handlers. The methods are documented and the constants are now defined
on the class. The bus use the service behavior with 'trigger_up'.
'bus.CrossTab' who extend 'bus.Longpolling' are instantiated by the
bus service.
The class is always instantiated with a parent, or root in the case of the website
(im_livechat), to use the ajax and localstorage services. So the behavior, perhaps
logger or redefined by the parents.
|
|
We use the registry keys as name for the services.
|
|
Since mailboxes are added after the rpc 'mail/init_message', the translations
are loaded. Therefore it is not necessary to lazily load the translations.
|
|
Before this commit, mail failures were correctly grouped in the
systray messaging menu, except for mail failures coming from channels.
This commit fixes grouping for mail failures from channel.
|
|
detached
When a new message is received and discuss is not open, any chat thread
containing this message is detached. However, if the thread is already
detached, it should not be detached again.
|
|
When we add a new message, it should re-render the thread only once.
The `addMessage` function must handles new messages and updated messages.
Some code for updated messages should not be executed for new messages,
which is what this commit does.
|
|
instantiation, thread `getMessages`/`fetchMessages`, and create mode document thread.
* = im_livechat, im_support
- thread widget now uses abstract thread in `render` method
- thread models have their `init` parameters changed, so that the parent may be optional
- reworked 'creating a new record...' in chatter in create mode:
> new model CreateModeDocumentThread, which basically is a fake document thread
with a fake message for its rendering in create mode of the chatter
> special rendering method of thread_widget for such case: `renderChatterCreateMode`
- renamed thread methods previously named `getMessages` to `fetchMessages`:
> in order to not conflict with `getMessages`, used for rendering
> now, `getMessages` always get messages that are locally,
while `fetchMessages` may fetch messages.
TODO:
- special thread model for im_livechat (rendering is broken ATM)
|
|
----------------------
Summary
----------------------
The purpose of this commit is to improve the JS code of the `mail` module.
It applies the new coding guidelines and makes some changes on the design
of some modules, such as the old ChatManager module.
Here is a short summary of the changes that have been made:
1. New coding guidelines
- snake_case to camelCase
- prefix private attributes and methods with '_'
- jsdoc on most methods
- one class per module
2. Rename/Merge some classes
- 'chat manager' becomes 'mail manager' (internal) and 'mail service' (external)
- 'chat window manager' is now included in mail manager
- 'thread' widget now named 'thread widget'
3. New model abstraction for mail objects:
- modules 'mail.model.*'
- modeling:
0..1 0..1 * *
ThreadWindow <------> Thread <-------> Message
/ \
/ \
Thread With Cache Document Thread
/ | \
/ | \
Mailbox Channel Support Channel
|
|
DM
- Thread: the superclass of threads.
- ThreadWindow: the window component of a thread.
- Message: mail objects representing messages.
- Thread With Cache: threads that can be used with search view (Discuss app compatible).
- Document Thread: represents the thread part of a chatter.
- Mailbox: represents what was previously called 'static' channel, e.g. 'Inbox'.
- Channel: mail objects representing channels, including livechat.
- DM: special kind of Channel for 1:1 communication in the backend.
- Support Channel: special channel for im_support module.
This new modeling approach let us easily add features on all threads, such as the
possibility to put any thread in a small window.
----------------------
Known issues
----------------------
[Already Present in Master]
1. When the Discuss app is in the background with 'Inbox' as the selected
Thread, when clicking on a document thread preview in the messaging menu
of the systray, the rainbow man appears.
2. When a document with the chatter is in the background, when receiving an
inbox notification from this document thread, the document thread is
automatically marked as read, which removes the notification right away.
3. Sometimes, opening a DM window from the "blank" thread window does not work.
4. Reply-to feature on Inbox is not working: no message is sent in the document
thread.
5. On the first login of admin user with demo data, the inbox counter is wrong
(it displays 6, instead of 3).
Explanation after investigation:
> On page load, it fetches the correct number of Inbox messages (3),
but the server notifies of 3 needaction messages right away,
so it wrongly assumes these are new needaction messages.
> Not possible for web client to detect that these messages should not
increment the Inbox counter while keeping same API.
6. Notifications for new document thread messages only work when the user sets
'handle with Odoo' for the Notification Management in the preferences.
> due to notifications on the longpoll bus for document thread
messages that come from needaction notifications.
> requires server-side changes to send notification on the longpoll
bus to mentionned user.
[New]
7. When receiving a message on a unjoined channel, thread window flickers
('open' > 'close' > 'open')
Explanation after investigation:
> JS logic:
a) On auto-join, ask server to join the channel and get channel infos.
b) The info tells the channel is not detached, but JS code makes decision
to detach it, and tells server the channel is now detached.
c) From (a), server notifies on longpoll bus the state of channel, which is
not detached. The web client thinks that the window state of the channel
has been changed somewhere else, and the channel is now closed.
d) From (b), server notifies on longpoll bus the state of channel, which is
detached. The web client opens the thread window of this channel.
> The flicker didn't occur before refactoring because the web client was only
updating the model of channel when it receives the longpoll notification.
> Server behaviour on 1st longpoll notification is necessary for cross-tab
synchronization for channel window state.
> New design implies that model and view should be synchronized, hence the
issue now.
> Solution: remove server-side thread window synchronization and replace with
client-side synchronization.
----------------------
Hacks
----------------------
The module `im_livechat` now uses mail objects that are compatible with Message
and Window objects:
Modeling for messages:
AbstractMessage
/ \
/ \
LivechatMessage Message
- AbstractMessage: message compatible with the thread widget.
- LivechatMessage: message used by im_livechat.
- Message: message used with the mail manager.
Modeling for thread windows:
AbstractThreadWindow
/ \
/ \
LivechatWindow ThreadWindow
- AbstractThreadWindow: behaviour share between all types of thread windows.
- LivechatWindow: window used by im_livechat.
- ThreadWindow: window used with mail_manager.
The reason for these hacks are twofold:
1. Use the thread widget in the frontend and livechat external lib bundles.
2. Do not have a dependency with the mail manager in the frontend and external
lib bundles.
|
