✨(backend,frontend) add configurable recording permissions

[gigi206]

Summary

• Add two new environment variables RECORDING_SCREEN_PERMISSION and RECORDING_TRANSCRIPT_PERMISSION to control who can start/stop recordings
• Support two permission levels: admin_owner (default, current behavior) and authenticated (any logged-in user)
• Allow room admins to override global recording permissions on a per-room basis via the admin panel

Changes

Backend:

• New RECORDING_SCREEN_PERMISSION and RECORDING_TRANSCRIPT_PERMISSION settings in settings.py
• New HasRecordingPermission permission class replacing HasPrivilegesOnRoom on recording endpoints
• Config API exposes permission levels to frontend
• Room serializer supports per-room recording_permissions configuration with input validation
• Read-only recording_permissions field in room API response (falls back to global settings)
• 18+ tests for permission combinations (global, per-room overrides, mixed, stop-recording)

Frontend:

• New RecordingPermission enum and shared useRecordingPermission hook
• useHasRecordingAccess and useHasFeatureWithoutAdminRights refactored as thin wrappers
• Admin panel: new recording permissions section with RecordingPermissionField radio groups
• RecordingPermissionsChanged notification to sync permission changes across participants
• i18n support (en, fr, de, nl)

Configuration:

• Environment variables documented in recording.md and kubernetes.md
• Helm charts and dev env files updated

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[gigi206]

Hi team 👋

Friendly bump on this PR — it's been open for about two months now without any review.

Quick recap:

• Adds two new environment variables (RECORDING_SCREEN_PERMISSION / RECORDING_TRANSCRIPT_PERMISSION) to control who can start/stop
  recordings
• Two permission levels: admin_owner (default, preserves current behavior) and authenticated
• Backend + frontend changes with 18 new tests
• SonarCloud Quality Gate passed, no conflicts with main

The branch is up to date and ready to review. I'd appreciate any feedback or guidance on what might be needed to move this forward.

[lebaudantoine]

Hi @gigi206 👋

Thanks for the PR and the detailed recap! I’ve quickly reviewed it, it does add a bit of complexity, and doesn't seem aligned with the product’s direction and potential benefits.

That said, I’d personally lean towards shipping the room with multiple admin/owner roles rather than loosening permissions around features that are critical for data retention and consent.

In other words, I’d prefer to give the owner the ability to add more owners/admins rather than allowing anyone to perform these actions (I know my phrasing is a bit caricatural 😅).

Happy to discuss further if needed!

P.S.: Our both teams should align before working on PR or a feature to make sure we don't lose time on both sides. Join Matrix, let's chat

[LNGGlago]

Hi,

I think giving "admin rights" to other people is an interesting feature, but this is not the exact same use case.

In a company, it happens a lot of time that a person create a meeting, cannot attend for any reason, so someone else leads the meeting. In this case, it might be ok to give rights to someone else. But now, let's think of hundreds of meetings created by a secretary for a member of the direction. You need to go on each meeting and give rights ? This is a huge loss of time.

Having this kind of parameter that companies can activate or not depending on their usecase and ONLY for logged in users (so people from the company) seems to be perfectly fine in the product without adding too much complexity (well, we could create user roles, and some roles could have access to all meeting et cetera, but I think it adds way more complexity to maintain).

Please reconsider accepting the feature, this is a real need for us and it is probably for all the structures.

Thanks

[lebaudantoine]

If a secretary generates a meeting link on behalf of someone else, they should grant admin rights to that person when creating the link. We have ongoing works refactoring the home page.

In some deployments, authenticated users are not necessarily part of the same company. Since we do not yet support multi-tenant deployments, we cannot reliably assume that all logged-in users belong to the same organization.

Because of that limitation, automatically enabling recording (or broader permissions) for all users from the same company is not currently something we can properly support. But that something we totally want to support.

That said, I could review and merge your proposal as a temporary or custom solution for your use case, until we implement a more advanced and properly designed feature.

Thanks.

[lebaudantoine]

@gigi206 CI is failing

[gigi206]

@lebaudantoine All CI checks are now passing.

[sonarqubecloud]

Quality Gate failed

Failed conditions
3.1% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[gigi206]

This PR has been rebased on upstream/main to resolve merge conflicts. The SonarCloud analysis seems to be based on a stale version of the code. The duplicated JSX pattern (RACSeparator + H + Text) reported in Admin.tsx has been refactored into a shared AdminSection component in the latest push (557e683).
Could a maintainer approve the pending workflows so the quality gate runs against the current code? If CI passes, is this ready for review/merge?