| Age | Commit message (Collapse) | Author |
|---|
|
When leaving the Jitsi meeting, if the participant is the last one, the
meeting participant count will still be 1.
To reproduce the error:
1. Go to Events
2. Create and Save an event
3. Go to associated Rooms
4. Create and Save room R
5. "Go to Website" (on R's form)
6. Join the meeting
7. Leave the meeting
- Use the "Leave" icon
8. Go back to R's form
=> "Participant count" is still set to 1.
This fix ensures the participant count will be 0 when nobody is in the
room. However, it will only work if the participant uses the "Leave"
button. So, for instance, if the last participant directly closes the window
to leave the meeting, the participant count will be incorrect. This is a
consequence of Jitsi which does not provide a way to get the number of
participants in a meeting (see file for more details, L119-142).
OPW-2416995
closes odoo/odoo#63583
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
Purpose
=======
There's one special case for the participant count update.
When we leave a room, if we are the last participant, we directly
update the participant count without waiting for the cool down (because
the participant might change the page and so the JS might not be loaded
anymore).
But, Jitsi made a change and now, when we hanging up the room, when
the event "videoConferenceLeft" is called, we are the only participant
in the list even if they're still other people in the room. So every
time someone hanging up the room, he will send the "zero participant"
update.
As we can not properly fix it (and be sure it will be "future proof"),
we dropped this update.
So now, some empty rooms might be marked as having one participant,
but no room will be marked as having zero participant if they are not
empty (and we prefer this behavior than the opposite).
Task-2350117
closes odoo/odoo#59369
X-original-commit: 84575078b80a7bf865ed52d1682548af3346ec14
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
Bug
===
When we implemented `website_jitsi` we didn't need to enter a pseudo. Users
automatically joined the room. But now we have one more step about entering
Jitsi username. During this step the room can become full so we need to check
one more time if room reached its full capacity.
Correctly use the option `check_full` in `website_event_track_exhibitor`.
Do not wait for participant update if the room become full.
Task ID-2345894
PR #58516
X-original-commit: 4aae31a7497b9f80b3c3f3d63a22bde646e09f0b
|
|
Purpose
=======
Allow to customize the domain name of the Jitsi server used
to create chat room on website.
This is done with an `ir.config_parameter`.
Task-2316718
closes odoo/odoo#55869
Related: odoo/upgrade#1618
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
RATIONALE
Events are sometimes held online, gathering a community. In this merge we
improve Event application to better support full-online events with improved
tracks, wishlists, chat rooms, ...
PURPOSE
Allow the website visitors to meet at online events using chat rooms. Those are
based on jitsi rooms previously added.
SPECIFICATIONS
Define a new model holding discussion rooms, with their target and a publish
management. Inherit from chat.room mixin to enable jitsi-based chat.
Any website visitor can create a meeting room based on Jitsi. Using some
information (name, summary, room size, languyage) anyone can launch a new
discussion topic. This will make a link with a new jitsi room enabling people
to chat. Visitor-community rooms creation can be turned off on event itself.
Meeting rooms can be pinned by the event managers to choose which rooms are
displayed on top. Managers can also duplicate the full meeting rooms if a topic
is popular, or publish/unpublish rooms like usual website records.
SPECIFICATIONS: LIST VIEW
Display a card-based list view of meeting rooms. They can be filtered by
language. When a meeting room reach the maximum number of participants it is
not visible anymore for standard visitors.
The meeting rooms unpinned are cleaned after a certain period of time if there
is no activity in it usign the autovacuum cron. That way we keep a clean view
on the frontend and we keep the important (pinned) meeting rooms.
SPECIFICATIONS: PAGE VIEW
Use the same main content / aside panel display as exhibitors / tracks, to
display the jitsi in the main content. Left panel proposes suggestions of
rooms, based on current one.
When a visitor join a meeting room, we fill the jitsi username with the name
he entered during his registration.
LINKS
Task ID-2252655 (Main Online Event task)
Task ID-2283742 (Community gathering on chat rooms)
Co-Authored-By: Aurélien Warnon <awa@odoo.com>
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
|
|
RATIONALE
Events are sometimes held online, gathering a community. In this merge we
improve Event application to better support full-online events with improved
tracks, wishlists, chat rooms, ...
PURPOSE
Build a mixin to create and manage jitsi-based chat rooms on website.
SPECIFICATIONS: CHAT.ROOM
Add a new model `chat.room` which contains all the configuration of the Jitsi
room.
A mixin `chat.room.mixin` adds a many2one to any model inheriting from it. That
way behavior is optional without adding all fields on the model. We just need
to inherit from the mixin and to use the chat room widget to build chat room
on website for any model that needs it.
SPECIFICATIONS: WIDGET
Allow to give a default username when logging to jitsi if customers are logged.
That way they gain a step and can directly participate to chat rooms.
SPECIFICATIONS: PARTICIPANT COUNT
Jitsi do not provide a REST API (or a similar API) to get the number of
participant in a room (without hosting our own instance of Jitsi). The
only way to get the number of participant is to be in the room and to use
the Javascript API. That's why the participant send in RPC the number of
participant in the room, to update the counter on the server side.
We can not ask the user who is leaving to update the counter, because he
can close the tab on his browser (and so the event will not be triggered),
so, the first participant in the room send the update in RPC.
Update of participant is done using SQL in non blocking mode so that concurrent
accesses are not an issue. Even if participant count is not really accurate
this is not an issue as managers will monitor rooms.
LINKS
Task ID-2252655 (Main Online Event task)
Task ID-2283742 (Community gathering on chat rooms)
Co-Authored-By: Aurélien Warnon <awa@odoo.com>
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
|
