* test_discuss_full
channel invitation to rtc calls are now using the `ChannelMember` and
`mail.channel.partner` models instead of the `partner` and `guest`
models.
part of task-2692836
closesodoo/odoo#95898
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit renames the isMuted variable into isSelfMuted to reflect the
user action of self muting, as opposed to the state of being mute,
which will be distinct in an upcoming commit.
part of task-2720026
closesodoo/odoo#82199
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this PR, the guest that just connect wouldn't receive the longpolling
message before the current one expire.
task-2664831
closesodoo/odoo#82170
X-original-commit: 0006123dba46d32d062a581e9a16f433f3ce05f3
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, the server could return outdated information to the
client about the state of their own rtc session.
The server should not return information about the client's own rtc
session as the source of truth is the client-side state.
A case in which this was causing an issue was when a user toggled their
mute state right before their client pinged the server and received
outdated session information before their most recent state could be
sent to the server.
This commit fixes this issue.
closesodoo/odoo#78028
X-original-commit: fe991edd2bca98b58fc5a49494871475c79bc22f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Post a message in the channel each time a guest is added to members of
the channel.
closesodoo/odoo#77915
X-original-commit: bf6af9b629a07d04bf582987b5144a37fa31729e
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = test_discuss_full
Before this commit if 2 persons are joining the call at the exact same time, the
join RPC of each will return the list of RTC sessions without the other person
included.
In more general terms, the server should actually rarely send the full state to
the JS (in this case "use the replace command") because there is no guarantee
that a concurrent transaction is not changing the data at the same time. In
other words, even the python is actually working with partial knowledge
relatively to the database.
Using a DB lock would guarantee it, but we don't want to lock tables and wait on
locks if there are alternatives. In this case it is acceptable to keep obsolete
sessions for a little bit longer, as long as they are cleared eventually.
closesodoo/odoo#77656
X-original-commit: d3a84172fc78f5783f75aa1155f1a25e4f9614b7
Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Didier (did)