- Aug 02, 2021
-
-
Ramon Souza authored
-
- Jul 08, 2021
-
-
Ramon Souza authored
-
Ramon Souza authored
-
- Jun 30, 2021
-
-
Anton Georgiev authored
-
- Jun 28, 2021
-
-
Joao Siebel authored
-
- Jun 14, 2021
-
-
Anton Georgiev authored
-
- Jun 04, 2021
-
-
Ramon Souza authored
-
- Jun 03, 2021
-
-
Anton Georgiev authored
-
- Jun 02, 2021
-
-
Ramon Souza authored
-
- Jun 01, 2021
-
-
Ramon Souza authored
-
Ramon Souza authored
-
- May 20, 2021
-
-
Ramon Souza authored
-
Ramon Souza authored
-
- May 19, 2021
-
-
Ramon Souza authored
-
- May 07, 2021
-
-
Ramon Souza authored
-
- Apr 29, 2021
-
-
Ramon Souza authored
-
- Apr 26, 2021
-
-
Vitor Mateus De Almeida authored
-
Anton Georgiev authored
-
- Apr 23, 2021
-
-
Mario Jr authored
Removed the reference for invalidateCookie, since it doesn't exist anymore.
-
- Apr 22, 2021
-
-
Ramon Souza authored
-
- Apr 16, 2021
-
-
Vitor Mateus De Almeida authored
-
- Apr 08, 2021
-
-
Anton Georgiev authored
-
Anton Georgiev authored
-
- Mar 31, 2021
-
-
Ramon Souza authored
-
- Mar 23, 2021
-
-
Pedro Beschorner Marin authored
Since Meteor was split in multiple process and events started to be filtered by instances, all Etherpad's Redis events were being discarded. Etherpad has a Redis' publisher plugin that is unaware of BigBlueButton's existence. All the communication between them is kept simple with minimal of internal data exchange. The concept of distincts subscribers at Meteor's side broke part of this simplicity and, now, Etherpad has to know which instance must receive it's messages. To provide such information I decided to include Meteor's instance as part of the pad's id. Should look like: - [instanceId]padId for the shared notes - [instanceId]padId_cc_(locale) for the closed captions With those changes the pad id generation made at the recording scripts had to be re-done because there is no instance id available. Pad id is now recorded at akka-apps and queried while archiving the shared notes.
-
Ramon Souza authored
-
- Mar 17, 2021
-
-
Ramon Souza authored
-
Ramon Souza authored
-
- Mar 16, 2021
-
-
Ramon Souza authored
-
- Mar 15, 2021
-
-
Anton Georgiev authored
I was shown a case just now where `CreateNewPresentationPodEvtMsg` can happen prior to the full add of a meeting. This log line becomes relevant once again
-
Anton Georgiev authored
Disabled `'Backend meeting queue had not been initialized'` which was added to pinpoint an issue with handling of meeting create events, but the issue seems to be unrelated (and has not been hit after resolving a memory leak)
-
- Mar 11, 2021
-
-
Ramón Souza authored
* moving locales folder to /public and applying changes needed to serve locales as static files * better dev/prod check * transifex pull script changes to match new locales directory + ignore locales with less than 100 lines * fix local/prod locales path * merge fallback messages * applies new locale changes to legacy client `bbb-html5.nginx` file content should also be changed to the following: ``` location /html5client/locales { alias /usr/share/meteor/bundle/programs/web.browser/app/locales; } location /html5client/compatibility { alias /usr/share/meteor/bundle/programs/web.browser/app/compatibility; } location /html5client/resources { alias /usr/share/meteor/bundle/programs/web.browser/app/resources; } location /html5client/svgs { alias /usr/share/meteor/bundle/programs/web.browser/app/svgs; } location /html5client/fonts { alias /usr/share/meteor/bundle/programs/web.browser/app/fonts; } location /html5client { # proxy_pass http://127.0.0.1:4100; # use for development proxy_pass http://poolhtml5servers; # use for production proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; } ```
-
- Mar 10, 2021
-
-
Mario Jr authored
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
-
Ramon Souza authored
-
Mario Jr authored
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
-
- Mar 08, 2021
-
-
Mario Jr authored
It is safer to look at subscriptions's state to users instead of depending on the initial state of the collection at mounting time. Although i couldn't force any race conditions on this, there's a chance it could happen. The fix avoid this problem. This complements #11533
-
- Mar 05, 2021
-
-
Mario Jr authored
Also removed unnecessary fields
-
Mario Junior authored
Co-authored-by:
Anton Georgiev <antobinary@users.noreply.github.com>
-
Mario Jr authored
Complements #11533
-
- Mar 02, 2021
-
-
hiroshisuga authored
-