Adds support for multiple cameras pins.
The pinned cameras are stored in a FIFO-type queue
When a camera is pinned the oldest one is removed.
The queue size can be set via create parameter 'maxPinnedCameras',
if not defaults to 3.
Include `meetingCameraCap` API param on create and enforce both server and
client to control the number of simultaneous webcams a meeting can have.
Disabled by default.
Include `userCameraCap` API param on create and enforce both server and
client to control the number of simultaneous webcams an user can share.
Default set to 3.
Replace the hardcoded guest's waiting timeout between polling requests - reference used
to remove a guest from the waiting list when the user leaves the waiting page - with a
bbb-web's configuration property.
Move all Etherpad's access control from Meteor to a separated [Node application](https://github.com/bigbluebutton/bbb-pads).
This new app uses [Etherpad's API](https://etherpad.org/doc/v1.8.4/#index_overview)
to create groups and manage session tokens for users to access them. Each group
represents one distinct pad at the html5 client.
- Removed locked users' access to pads: replaced readOnly pad's access with a new pad's content sharing routine
- Pad's access is now controlled by [Etherpad's API](https://etherpad.org/doc/v1.8.4/#index_overview)
- Closed captions edited content now reflects at it's live feedback
- Improved closed caption's dictation mode live feedback
- Moved all Etherpad's API control from Meteor to a separated [app](https://github.com/bigbluebutton/bbb-pads)
- Included access control both in akka-apps and bbb-pads
Includes a new create param/web conf called allowModsToEjectCameras, false by
default.
Ejection does not work in breakout rooms or with non-mod users
Ejection closes _all_ webcams shared by the target user
Add an option to set a default logo to be placed for all created meetings.
The default logo is inserted as a create meeting param for all meetings that
do not have a `logo` param defined. Two new properties were included at
bigbluebutton-web configuration:
- [Boolean] `useDefaultLogo`: enables/disables the use of the default logo
disabled as default
- [String] `defaultLogoURL`: The default logo URL to be fetched by the client
bigbluebutton logo as default
Changes to the current (v2.2) default configuration of the guest feature.
The ideal is to keep the simplified guest feature as default (`authenticatedGuests=false`)
but we also need to be in sync with Greenlight settings to make this happen.
Greenlight will have to re-add the `guest=true` param on user's join API call when ASK_MODERATOR
is set as guest's policy.
This patch includes two improvements made for bbb-web. It tries to better isolate
the sessionToken's handling and session's validation, including logs for each one of
these steps; and removes maxParticipats control from registered users (that are no
longer removed from bbb-web collections) binding it to joined users or users that
reached the enter API call. The following adds more details about this last one:
User's regular flow to join a meeting goes around an API join call -> redis register event ->
redirect to client page -> API enter call -> redis join event. When the guest policy is ASK_MODERATOR,
non-moderators are registered and redirected to a guest lobby that polls for her/his guest status and
only enters the meeting after a moderator approval.
Using registered users as control to check how many participants are in a meeting is problematic because
non-approved guests are counted as participants and bbb-web has to find out when to ditch registered users
records to make a seat in a meeting available again. In other words, a meeting with maxParicipants
of 5 can get it's joins locked with a moderator and 4 waiting guests or bbb-web can wrongly drop a registered
user record on a reconnection inducing weird 401 responses from the API.
This change proposes to control maxParticipants both at join and enter API calls monitoring the number
of redis joined users. This also includes an extra buffer to capture users that called the enter API but
still don't have an user joined event.
User left events are now handled different holding the user data before removing from the joined users collection
and only releasing after verifying that the user didn't reconnected.
Both user left timeout `usersTimeout` and entered user timeout `enteredUsersTimeout` can be configured at properties.
