It introduces the mutations:
chatEditMessage
chatDeleteMessage
The type chat_message receive two new fields:
updatedAt
deletedAt
A new table chat_message_history was introduced to store the previous version of an edited or deleted message.
When removed the message is not deleted, but the content become null and deletedAt populated. So the idea is to show "This message was removed" in the client.
Add fields:
contentType: to identify whether is camera or screenshare
hasAudio: useful for screenshare
focused: indicates if this screenshare will be shown in presentation area
replyToMessageId will be useful for the feature that enables to reply a message of the chat
messageSequence will be useful to identify the page of that message and scroll the user to the correct page when they click to see the original message
Closes https://github.com/bigbluebutton/bigbluebutton/issues/21161
As suggested by @danimo the client files for bbb-html5
are not variable/dynamic content and are a better fit for /usr/share
than for /var/bigbluebutton (where they'd also be in the way of
recording files)
Previously, we checked if a presentation existed before inserting it into the database. However, concurrent checks sometimes led to race conditions where the same presentation was inserted twice, causing errors and blocking subsequent page additions. This update removes the existence check and directly attempts to insert the presentation using an "IF NOT EXISTS" clause. This streamlines the process, enhances performance, and prevents ID duplication errors.
Ensure that the GraphQL reconnection—and thus the user's Hasura role update from `bbb_client_not_in_meeting` to `bbb_client`—occurs before the client is informed they've joined (`joined=true`). This prevents a race condition where the client might send GraphQL queries before having the necessary permissions, as only `bbb_client` can perform most queries. By updating the role first, we guarantee the client can successfully execute queries after joining.
Starts supporting the param enforceLayout, a subsequent PR will finish and document it
Starts supporting user-session-metadata, a subsequent PR will finish and document it
When a shape is changed, the full shape objcect was being transmitted to the server again.
Do a diff to only send what changed (similarly as it was in tldraw v1) to save upload bw.
TODO:
Draw segments diffs (array) is still not working, so all the segments are still being sent every time.
This commit introduces `userLockSettings`, which includes an option to set `disablePublicChat` for specific users, rather than only for all locked viewers as before. This implementation covers the backend and GraphQL portions; the frontend changes will be addressed in a separate PR.
This is a port of #20585, originally implemented for version 2.7 using the old architecture with MongoDB.
Additionally, the mobile app can use this feature to render the whiteboard inside an iframe with the same `userId`.
By setting the parameter `revokePreviousSession=true`, a new `sessionToken` will be generated, and the previous session will be revoked when the new device connects. This is useful for transferring a session to another device and automatically closing the previous session.
Dial-in endpoints currently follow the same guest approval process as regular
users. While this is correct for default installations, it complicates the join
procedure in setups where approval is managed externally, such as with pre-
configured conference PIN codes. Another relevant scenario is when call
origination is done from BBB, rather than as an inbound call.
This commit makes the enforcement of the guest policy for dial-in/external
endpoints optional in akka-apps. The default behavior remains unchanged
(enforce). This provides more flexibility for the dial-in mechanism, allowing
for smoother handling of the scenarios mentioned above.
The current default setting of muteOnStart=false can lead to performance
issues in larger rooms, especially with the "transparent listen only
mode" and LiveKit, as proven by load testing. In contrast,
muteOnStart=true helps mitigate these issues but complicates the entry
process for smaller meetings, such as 1-on-1 sessions or small classes.
Additionally, the ability to override muteOnStart via the API can create
scalability issues if not managed properly.
Add a new akka-apps flag `voiceConf.muteOnStartThreshold` which acts as
a trigger that forces muteOnStart=true when the number of audio
participants reaches the configured threshold. 0 means no threshold
(disabled).
This trigger overrides any API parameter or static configurations
related to muteOnStart, as well as the client's meeting mute actions.
Pending:
- Remove MeetingStatus.meetingMute state side effects from the client's
"Mute all" and "Mute all except presenter" actions. They should no
longer alter the meeting mute state once this becomes default (just
mute users instead).
FS has an intermittent issue where unmuting a HELD channel sometimes
takes significantly (seconds) longer than usual.
conference <XYZ> unmute <WVU> simply gets stuck with no FS_API response,
which delays the unmute action whenever transparent listen only is
active.
Apparently, unholding the channel PRIOR TO unmuting works around the
issue - at least it could not be reproduced with the scenario at hand.
The unmute API already triggered an unhold in FS internally, which is
the reason why this was not done beforehand. The aforementioned issue is
way worse than an extra "redudant" API call, though.
Always unhold audio channels manually _before_ unmuting.
FreeSWITCH incorrectly generates callerNum headers in its ESL events
when specific, special characters are in place. e.g.:
w_etc_0-bbbID-User;Semi (notice the semicolon) will be generated by
FS as w_etc_0-bbbID-User (everything after the semicolon is ignored).
This breaks callerId comparision for session matching in a few places -
one of the is the unmute/unhold toggle control.
Compare callerNum as prefixes instead of exact strings to match those
scenarios.
This is a temporary fix; we should review callerNum generation in the
future (use Caller-Id-Name in FSESL), as well as stop relying on it
for session matching (use UUIDs and/or client session numbers instead).
Both of these are more involved changes, though.
Whenever both microphone lock settings and transparent listen are
active, users fail to join audio due to an oversight in the audio join
permission procedure. It's denying users from *joining* audio if they're
locked, even though they should only be prevented from *unmuting*
themselves.
Change the permission checks for audio join to allow users even when
they're locked. Use the lock setting to force the muteOnStart flag for
locked users instead.
Alway send the unhold command since it doesn't change flip the state
(contrary to the uuid_hold toggle command).
It's not idempotent, though - so always update the internal hold state
to prevent state mismatches preventing channels from being unheld.
