* Option to disable new chat features like edit, delete, reply and send-reaction using the param disabledFeatures"
* Revert documentation while recording portion is not ready
It introduces the graphql prop `reactions` to the type `chat_message_public` and `chat_message_private`.
It also add two mutations `chatSendMessageReaction` and `chatDeleteMessageReaction`.
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.
