It is not available due to cross-origin or not able to start setCaptureHandleConfig in iframe.
error 1: Failed to execute 'showSaveFilePicker' on 'Window': Cross origin sub frames aren't allowed to show a file picker.
error 2: Failed to execute 'setCaptureHandleConfig' on 'MediaDevices': Can only be called from the top-level document.
Setting the UA string in Electron doesn't propagate the change to the
iframe where the meeting is loaded (🤦).
Thus make it more resilient by trying different things:
- A freshly introduced "iAmSpot" config option, similar to Jibri
- The app ID is present in the UA string, so we can test for that
- As a last-ditch effort, check if the display name is the default
"Meeting Room"
When turned on, the consent dialog won't be displayed for the users who
are already in the meeting, it will only be displayed to those who join
after the recording was started.
A given recording should only trigger a single consent request.
The mechanism to notify about recording status updates may fire multiple
times since it's tied to XMPP presence and may send updates such as when
the live stream view URL is set.
Rather than trying to handle all possible corner cases to make sure we
only show the consent dialog once, keep track of the recording session
IDs for which we _have_ asked for consent and skip the dialog in case we
have done it already.
Use the `showSaveFilePicker` File System Access API to pre-select the
file for download and stream the contents there. The browser uses a
temporary file as the buffer, thus not requiring us to buffer the
contents in memory.
Also change the container to MP4, since we have no way to fix the
seeking problem since we don't have the file in memory. Good news is
that it's supported since Chrome 126 and we can feature detect it!
Finally, add a helper `isSupprted` method which feature-detects
everything we need to make this work.
Ref: https://developer.mozilla.org/en-US/docs/Web/API/Window/showSaveFilePicker
Ref: https://groups.google.com/a/chromium.org/g/blink-dev/c/p1OMVj1FrMI/m/6FdLk7rZAQAJ
When any of the backend is used 'anonymous', 'jitsi-anonymous', 'internal_hashed', 'internal_plain', 'cyrus' and a participant becomes a moderator, because of external module or because set from jicofo we send to client with the self-presence about becoming moderator a default set of permissions which can be controlled via prosody config.
If using 'token' authentication the above applies only if there is a token and the token does not contain context.features.
* fix(transcriptions): Uses dial command to invite transcriber.
* fix(transcriptions,recording): Allows non moderators with features to dial, record or transcribe.
* sqaush: Make sure filtering works when only is a moderator.
It works now and without a token and no features, but being moderator.
* squash: Rename constant.
* squash: Checks features first before defaulting to moderator when filtering metadata service.
* squash: Checks features first before defaulting to moderator in UI.
* squash: Fixes lint and one other check.
* squash: Moves more logic to is_feature_allowed.
* squash: Drops unnecessary check.
* squash: Uses constant coming from ljm.
* squash: Toggles back captions button on error.
* squash: Fix comment.
* squash: Reverting back isLiveStreamingButtonVisible.
* squash: Fix imports.
Until this commit we didn't make difference between transcriptions from the recording dialog and subtitles. Now subtitles are not considered recording anymore and only the transcriptions started from recording dialog are considered recording.
