feat(recording) - add frontend support for recording consent

[Antreesy]

☑️ Resolves

• Fix Frontend "Recording consent" #10409
• Solution is based on MVP + V2 description (⏺️ Recording consent - Overview #10348 (comment))
  • Option to require consent globally in Admin settings
  • When consent is required 1:
    • Enforce the media settings dialog
    • Show a checkbox that needs ticking before moderator/user can start or join call
    • Moderator setting is visible but disabled
  • When consent is optional 2:
    • Moderator setting is enabled with "Off" and "Required"
    • Disabled, while call is currently on
  • If user accidentally joined without consent, will be blocked by API
• Increase preview size in MediaSettings, align all content elements up to its width

🖌️ UI Checklist

🖼️ Screenshots / Screencasts

Admin settings

Moderator settings

Off (hidden)	Required (disabled)	Configurable V2

User view (Media settings)

Off (hidden)	Required (not checked)	Required (checked)

🚧 Tasks

• Adjust wording / styles
• Test with recording package
• Test frontend (enter in AdminSettings -> Recording backend credentials for working signaling server)

🏁 Checklist

• 🌏 Tested with Chrome, Firefox and Safari or should not be risky to browser differences
• 🖌️ Design was reviewed, approved or inspired by the design team
• ⛑️ Tests are included or not possible
• 📗 User documentation in https://github.com/nextcloud/documentation/tree/master/user_manual/talk has been updated or is not required

[Antreesy]

cc @marcoambrosini for design review and wording for MVP + V2 solution
cc @danxuliu as it touches signaling, to ensure it won't break anything

[marcoambrosini]

The wording seems ok, I'd style the component a bit differently, similar to the quote component:

• border instead of background (better text contrast)
• Rounded corners
• Rounded warning bar on the left
• No warning icon
• Same width as the video component above

Quick sketch:

[nickvergessen]

I'd style the component a bit differently

It's the wode spread NcNoteCard component. If that should be restyled, I'd should be done upstream I guess.
The usecase is exactly what the component was designed for 🙈

[danxuliu]

There are two cases in which joining a call fails if recording consent is enabled: switching between breakout rooms and requesting the password of a share (video verification). In those cases the recording consent is not asked, so the API prevents the user from joining the call.

How to test (scenario 1):

• Open Talk settings
• Enable recording consent for all calls
• Create a new group conversation
• Add another user
• Set up breakout rooms with 2 rooms
• Start a call in that conversation; as it is the first time that a call is started the media settings screen will be shown
• Give recording consent
• Start the actual call
• In a private window, log in as the other user
• Join the conversation
• Join the call; as it is the first time that a call is started the media settings screen will be shown
• Give recording consent
• Join the actual call
• In the original window, start the breakout rooms session

Expected result

The user switches to the call in the breakout room (I would say that asking for recording consent again would be overkill and that the recording consent from the parent room should be reused; maybe this could be even done in the API itself)

Actual result

The user switches to the call in the breakout room, but is immediately kicked out

How to test (scenario 2):

• Open Talk settings
• Enable recording consent for all calls
• Open the Files app
• Create a link share
• Protect the share with a password
• Enable video verification
• Copy the link
• In a private window, open the link
• Request the password
• Set a name for the guest

Expected result

The media settings screen (or just a recording consent dialog, but I guess it would be better to reuse the media settings screen) is shown to give recording consent

Actual result

The user seems to join the call but is immediately kicked out

Independently of that, the media settings screen should be shown even if the user unchecked Always show preview for this conversation when recording consent needs to be given to join a call:

How to test

• Open Talk settings
• Enable recording consent for all calls, or make it optional and enable it in a specific call
• Create a new conversation, and if recording consent is optional, enable it
• Start a call in that conversation; as it is the first time that a call is started the media settings screen will be shown
• Uncheck Always show preview for this conversation
• Give recording consent
• Start the actual call
• Leave the call
• Reload the page
• Start a call

Expected result

The media settings screen is shown to give recording consent

Actual result

The user seems to join the call but is immediately kicked out

[nickvergessen]

Case 1 (sending to breakout room) I guess we can fix on the API level by ignoring the setting there and basically allow "sending users" there. However when stopping breakout rooms they would join the parent again in which case we can not detect on API level if that is happening, so we would require the client to send the consent flag there again.

[nickvergessen]

However when stopping breakout rooms they would join the parent again in which case we can not detect on API level if that is happening, so we would require the client to send the consent flag there again.

But that is also a bit annoying, because it will be listed as another consent entry, but I guess it's the best step we have atm

[nickvergessen]

The reconnection when your permissions are modified is also affected?

[danxuliu]

The reconnection when your permissions are modified is also affected?

Good catch. Yes, reconnections do not work because the consent is not sent again. The silent parameter is not taken into account either, I will check tomorrow as that might need a separate fix to be able to backport it (and therefore this pull request would need a rebase on that fix to be able to also fix renegotiations when consent is required).

[marcoambrosini]

@Antreesy I think the use of selects here is not appropriate.
I think that the admin settings should be radio buttons, with an explanation always shown and not in a warning badge.
On the other hand, for the moderators on a per-conversation basis, we should use a toggle.

[danxuliu]

The silent parameter is not taken into account either, I will check tomorrow as that might need a separate fix to be able to backport it (and therefore this pull request would need a rebase on that fix to be able to also fix renegotiations when consent is required).

Fix for silent parameter is in #10688 The second commit can be used as a reference on what to change (after rebasing) to send the consent again on reconnections.

[danxuliu]

The media settings screen is not shown if the user unchecked Always show preview for this conversation when recording consent needs to be given. Please refer to the last How to test section in #10633 (review)

Independently of that, the consent sometimes is sent again and sometimes it is not when using breakout rooms (first How to test section in #10633 (review)). I have not been able to find a pattern, maybe it is related to fetching the room information to compare the parent room when switching to a different breakout room to clean or not to clean the consent, but I do not know.

When requesting the password of a share it might be good to leave the room if the media settings screen is closed without joining the call. Leaving the call or the conversation should update the sidebar and remove the call view and the chat and show This conversation has ended, although it seems that was lost at some point 🤔 As leaving the call does not currently do that I guess it would be fine to leave the conversation when the media settings is closed in a follow up once the existing code was also fixed.

To end in a bright note, the consent is now sent again in forced reconnections :-)

[Antreesy]

...if the user unchecked Always show preview for this conversation

I might have lost these code lines... Moved logic from components to the store, to sync it properly between MediaSettings, ConversationSettingsDialog and CallButton (tests included) 🟢

...maybe it is related to fetching the room information

I have relied on breakoutRoomsStore, but it works differently for moderators and non-moderators. Fixed 🟢

Leaving the call or the conversation should update the sidebar and remove the call view and the chat and [show This conversation has ended]

with internal signling only, we fetch conversation within an interval, and show context you mentioned. but with HPB it wait for signaling message. Don't know the logic here (cc @nickvergessen), but it seems like when the share owner leaves conversation, it's removed on server side. So, we may track signaling message, that owner left the room, and fetch the conversation within some timeout => and if it was deleted, all should go back to normal => will raise a follow-up issue

[DorraJaouad]

In case the consent is configurable on conversation level, I noticed when a moderator switches on the consent requirement while a participant has the conversation open ( on a chat view), it's not updated for them thus there is no consent requested when joining the call.

[nickvergessen]

In case the consent is configurable on conversation level, I noticed when a moderator switches on the consent requirement while a participant has the conversation open ( on a chat view), it's not updated for them thus there is no consent requested when joining the call.

Missing an update trigger via the HPB then, so it's a backend issue.

[nickvergessen]

In case the consent is configurable on conversation level, I noticed when a moderator switches on the consent requirement while a participant has the conversation open ( on a chat view), it's not updated for them thus there is no consent requested when joining the call.

Also fixed in #10727 now

[Antreesy]

Rebased onto master, should work for breakout rooms, and fetch conversation on change
Consent is kept for main view and sidebar integrations (turns out it's possible to promote people to moderators there with occ command at least)

Vacationing

[DorraJaouad]

Breakout rooms session should be closed when the moderator wants to toggle the consent requirement in the conversation settings . It renders Bad request otherwise ( maybe add a hint in toast ? )

Overall, nothing is blocking 🦅 .

Dismissing

[danxuliu]

(I did not see that the review was dismissed before actually testing the pull request 🤦)

Tested and works 👍

A minor detail: when the device selector is shown in request password/video verification clicking on Always show preview for this conversation or in the menu to start a silent call has no effect (the checkbox is not modified, and the menu is not opened).

Nevertheless, those options should not be even visible, because every time a password is requested again a new room will be created, so there is no point in remembering Always show preview for this conversation, and the call should not be silently started, as the owner of the file should be notified that a password is being requested.