Depending on the sequence of events on the server, user sometimes is
added to the users collection with the name information, and sometimes this
information is updated in a second moment. Once we need the username
to show the push notification, we observe changes on this field for both
added and changed event.
Closes#11307
When validating tokens, the dummyUser created at the beginning is set
with validated=true. This means there won't be the state change that used
to occur from validated:false to validated:true (which detects the moment
joined the meeting) , therefore the alert code that expects for this change
won't run.
To fix this for audio alerts, we now detect when user join by observing
additions in Users's collection. This is actually good because we start
observing this only once (in componentDidMount), differently we used to do,
by calling this every time the tracker was activated.
To distinguish between the user addition that initially populates user's
collection from those that happens after user join (which are the ones we
want), we store the initial state (at componentDidMount) and compare it
with new additions. If the user added is present at the initial state,
then it is an addition to populates the collection, otherwise this is a real
user addition (happened after user joined the meeting)
Partially fixes#11399
Currently this information is lost everytime breakout-room component is
unmounted, causing the panel to shows wrong information during next renders
Fixes#11333
Without 'exact' match, the browser fallbacks to the default inputDeviceId
This prevents the error (input device error) when breakout is ended and we try
to skipCheck the microphone when user returns to main room (assuming the
user had the microphone active before joining breakout room).
After ending the notification playback, we set the ".src" property to null, which immediately stop the internal player of mobile browser (tested on Chrome for Android - device list is on #11458).
For the specific list of devices, this prevents the internal buffer error "-61" described in #11458.
Fixes#11458.
After audio reconnection, a muted user would have it's microphone unmuted by default, unless muteOnStart is set to true. This fix this problem.
Fixes#9016
Associate pads with meetings so session validation is restricted to the
meeting's valid session tokens.
Meteor will dispatch new redis events on shared notes and closed captions
pads creation. This event will go through apps and reach web to populate
a new meeting's pad collection that contains all valid pad id's for that
session. Nginx will use this collection to check if the user's session token
belongs to the pad's authorized users.
Besides these modifications, an extra change will be needed at notes.nginx.
Location /pad/p/ needs to change it's auth_request:
from /bigbluebutton/connection/checkAuthorization;
to /bigbluebutton/connection/validatePad;
When managing Etherpad's pads, Meteor makes API calls to initiate the closed captions
and shared notes modules. The pad id was being mapped to a shorter id than the meeting
id because of a Etherpad lenght limitation.
Changed to something less guessable.
One of the main issues in 2.2.x problem reports currently in the wild in social media and in the bbb admin groups seems to be that people turn a couple of webcams on and the clients or the server already can't handle it any more. In most cases, enabling video-pagination for mobile devices and also cameraQualityThresholds already "solves" the problem and makes it possible for much more students to attend online-class as well as raise acceptance of using BBB instead of other commercial services.
Even after promoting these new settings for weeks, many BBB operators still don't know of them and are surprised and happy once they enable it.
This change contians rather high values so that admins see that these features exist, but typical use cases which might not want video-pagination enabled (typical 28people school class) are still not "annoyed".
When multiple actions were bolted in the dropdown (mirror, focus), keys were getting duplicated with cameraId. Make them unique based on the action`s name
Recent fix to the stop all cameras behaviour exposed a bug where the local camera connecting state wasnt being cleared up when a camera timed out before being successfully shared
The debounce method argument was being passed wrong (its supposed to be a method, not a function call), thus spewing exceptions in the console and rendering the debounce virtually ineffective
