sometimes, the web client receives unsubscribe notification and an extra
notification on that channel. This is then followed by an attempt to
rejoin the channel that we just left. This commit prevents that
situation to occur.
For that, it needs to know the notifications received by the bus in one
batch, not one at a time.
This commit introduces native notifications (if available) to the
discuss application.
Those notifications will only appear if the user grants the permission
for that. A notification bar will appear in the discuss application if
necessary to prompt the user.
Also, it always is the master bus that will be the one sending the
notification.
For this change, it was necessary to be able to detect if the user has
the focus on some other odoo tabs. For this reason, the bus was
extended.
Commit 5d1b323. re-enabled the user presence updates and notifications.
Unfortunately, it showed poor performance due to the high frequency of bus
notifications triggered on our instance (~600k users).
In this rev., we don't trigger notifications on presence changes anymore, but
we rather send the presence of users we have a DM open with, at the end of each
poll period. For performance reasons, we ensure not to do that more than once
every 30 seconds.
We also refined the detection of the 'away' status client side. 'Last presence'
timestamps are stored in the local storage, and the current inactivity period
is sent at each poll. Those presence timestamps now rely on browser activity
detection (click, keypress... events) rather than on the focus on Odoo tabs.
Finally, we removed the no more necessary cron introduced in 5d1b323.
Before this rev., no notification was sent on the bus when the user presence
changed. Thus, the bullets displayed in Discuss were never updated and stayed
as they were on the initialilization of the chat_manager (on webclient launch).
This rev. makes the bus.presence notifications work, and handles them client
side.
Moreover, the disconnections detection is now performed at each poll (with a
maximum of 1 per minute), instead of randomly (1/100 chance) at each poll, as
it scales better than the former solution. We also added a cron that performs
this check every 5 minutes. It is needed to detect that the last connected user
just disconnected (useful for visitors in the website, trying to talk with a
livechat operator).
Also, the 'away' status is now handled client side, as it makes more sense
that way (being away at each poll, e.g. every 50seconds, during 10 minutes
doesn't mean that we didn't come back between two polls).
Finaly, in bus.js, CrossTabBus, we moved the code writing in/reading the local
storage after the tab registration as this code depends on the fact that the
tab is the master tab or not (and this is known only once the tab is
registered).
This rev. was necessary in stable because the livechat uses the user status to
detect if there is an operator available, and this was often inaccurate.
Moreover, it improves the user experience of the chat in the backend.
On browser refresh, the bus sends the last notifications for the last
50secs. This is really annoying to deal with, especially in the chat
applicatiion. This commits ensure that duplicate notifications are
ignored. This is done by saving the id of the last notif in the local
storage.
Note: it is also necessary to clear the last message id in the local
storage to prevent problems when a developer resets his db, and will not
receive any notifications.
The problem was that the tab_manager compared its last heartbeat value with an
old value stored in the local storage (when being elicted master, the tab
writes a new heartbeat in the locat storage).
This solution makes sure to compare the actual value in the local storage with
the heartbeat value stored in the tab_manager.
The bus is somewhat tricky. (at least, the crosstab version). It needs
to elect a leader, and to communicate with the server through it.
However, several tabs have a different event loop, so, we need to be
careful to avoid race conditions. The current version was not
race-condition-proof, and this commits improves on this.
The idea is to allow the bus to detect if some other tab is also
considering himself master. In that case, it is allowed to unelect
himself.
This should allow the bus to self correct those situations in a short
time.
The bus used to do a long poll as soon as it is started. This is fine
when the user has a single tab, but not so fine when 5 or 6 tabs are
open. This commit introduce the concept of tab manager, a way to decide
among all tabs who is the leader. The leader will then initiate the
long poll, and share the notifications via the local storage.
The bus was allowed to restart polling, client side, to allow the user
to directly receive messages in new channels. This was only acceptable
as a temporary fix, the correct way to do this is to actually notify the
bus server side. This is even more urgent since the client was allowed
to keep multiple longpolls simultaneously, which degraded the experience
in some cases.
The problem was that the bus didn't listen to new channels when they were
registered until the end of the current longpoll. This allows mail to manually
restart the polling.
- im_chat.session will be replaced by mail.channel
- im_chat.shortode is renamed into mail.shortcode
- im_chat.presence is moved to bus module
- js and controller code is moved from im_chat to mail module
This commit only move files, and modify manifests, bundles, ... The code will be adapt in the next commits.
The module system needs to know the dependencies of a given module
before executing the function. This is why the dependencies were
defined once in an array, and then were described one more times in the
call to require.
But a trick can simplify this: the boot function can parse the string
representation of the module and extract the calls to require from it.
It is more work for the processor, but it leads to simpler module
definitions.
1b9c404 modified the /longpolling/poll requests
to use openerp.session.rpc() instead of openerp.jsonRpc().
In order to properly disable error popups, an
explicit preventDefault() call is now required.
Add a generic bus for instant communication based on postgres LISTEN/NOTIFY and HTTP comet.
Both threaded and gevent greenlet mode are supported. Chat should now work on every platform.
im_chat improvements
- proper support for multiple windows
- present, away and offline status
- improved data model for multi user chat session
im_livechat improvements
- standard css js assets are now used
- qweb templates are now used instead of jinnja
Adrien Dieudonne