Before this commit:
When user tries to create an event meeting room without selecting
'Max Capacity', it throws a Validation Error because 'Max Capacity'
is a required field.
After this commit:
We provide the default value for 'Max Capicity' field on event meeting
room to avoid default ORM Validation Error while saving the record.
Note: Because the 'Max Capacity' is a selection field, displayed with
radio widget, we can't make it required from the view unlike other fields.
Also, in the 'chat.room.mixin', when we create a chat room on the fly from
create method, instead of popping the ROOM_CONFIG_FIELDS, we propagate them
(same like in write method), so that the room being created respects value
selected by user (instead of taking the default one if we pop it).
Task-id : 2448435
closesodoo/odoo#72756
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
SPECIFICATIONS
Slightly improve meeting room model
* set chat room as required. Meeting rooms without chat room make no sense;
* allow to translate room summary. As this is displayed in frontend having
it translated makes sense;
* improve label of reached participants, allowing notably to display it
nicely in backend;
LINKS
Coming from internal feedback while deploying online support
Task ID-2314778
PR #55887
X-original-commit 54bd8281cf94ddee77073cf5d6356d847d08d024
PURPOSE
Ease chat room management, especially when dealing with meeting rooms and
exhibitors in backend: multi edit, avoid name collision, better support of
copy with room names, ...
SPECIFICATIONS
Clean code managing chat rooms: handle most of its management in chat room
mixin. It allows to lessen custom code in website_event_meet.
Improve sanitize heuristic of chat rooms by avoiding name collision. If a
room with a given name already exists, simply increment a counter as suffix.
Improve copy management: when copying from the chat.room.mixin on a record
with a room set, simply propagate an updated room name. As room_id itself
is not kept but a new one is create, it will create a new room with a name
avoiding collisions.
Allow multi edit for event meeting rooms and exhibitors. It allows notably
to publish by batch, and to set exhibitors as having chat rooms by batch.
Give default values for max participants count when creating exhibitors so
that required field has a default value. Otherwise people forgot it and have
to come back on form view to set it. This is due to default value coming
from mixin not being propagated to the form view.
LINKS
Coming from internal feedback while deploying online support
Task ID-2314778
PR #55887
X-original-commit d35d6295ae1b50e9ecb4e57c5e7fb6cdd52c8b27
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
closesodoo/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>
Yannick Tivisse