Display two initials in the Avatar whenever the participant's name
allows it, instead of a single letter.
A single initial makes it too hard to distinguish participants when
their cameras are off, especially in larger
Rework how the participant name is displayed in the participant
list to show as much of the name as possible before truncating.
When the name has to be truncated, add a tooltip so users can hover
to see the full name.
Requested by users.
Add a visual badge on participants who are not authenticated, so it
is immediately clear who could be an anonymous participant. This is
a small but explicit security signal in the participant list.
Beyond that, the badge also plays a functional role: since only
authenticated participants can be promoted or demoted, the badge
helps users see at a glance who is eligible for a role change.
Since the username refactoring, the username in the store could be
undefined when the join input was pre-filled from user.full_name,
because no keystroke was needed to populate the store.
This led to a 400 error on the request-entry endpoint whenever the
user joined without editing the pre-filled name.
Fall back to user.full_name when the store username is missing, so
the endpoint always receives a value.
Acknowledged as a somewhat wobbly fix, but ships as-is until the
underlying flow is reworked.
Listen to role changes in the admin panel and close the side panel
if the current user is demoted while it is open. Without this,
unprivileged users could still see the admin side panel until they
closed it manually.
I checked the other features that could be affected by hot role
changes; this was the only one still exposing admin-only UI after a
demotion. Everything else already handles live permission updates
correctly.
Introduce a new feature that lets a user promote one of the
authenticated participants of the meeting to a role with additional
privileges.
Known limitations:
* Only authenticated participants can be promoted, but there is no
visual indicator yet distinguishing authenticated from anonymous
participants. This will be added in a follow-up commit.
* The resource_access data fetched in the initial API call becomes
stale after a promotion. It is not currently used in the product,
so this is not visible, but it should either be refreshed later
or removed from the initial fetch.
* Demoting a promoted user turns them into a member, which is still
a privileged role. This is a deliberate choice until we introduce
finer-grained tuning of participant roles.
Extract the logic that closes the side panel into a utility function
declared at the store module level, as recommended by Valtio.
This avoids re-creating the function on every render and prevents
extra re-renders in components that use it.
The API serializer was too restrictive on the `sub` field, expecting
a UUID. This worked in our development and production setups because
our Keycloak is configured to emit UUID subs, but it broke for other
providers.
Per the OIDC spec and the DB model, `sub` can be any string. Align
the serializer with this and accept arbitrary string values.
Fixes#1525.
Uppercase the initials rendered in the Avatar so their vertical
centering stays consistent.
With lowercase letters, the initials were slightly shifted toward
the bottom of the Avatar, which broke the alignment.
The is_administrable flag was previously read from the room API
response through the room serializer, giving the frontend static
information about the user's rights.
Refactor the frontend so it derives this flag from the participant
role carried in the participant metadata instead.
Two benefits:
* The flag now updates live along with the participant
attributes/metadata, so role changes are reflected immediately.
* It removes the duplication between the API response and the
metadata, which both used to determine the user's capabilities.
Include the is_authenticated flag on the user in the LiveKit token
and participant metadata.
The frontend needs this information (used in the next commit) to
know whether it can offer to promote a user with access to the room
admin.
The backend previously passed an abstract is_admin_or_owner boolean
flag in the LiveKit token. That kept the frontend minimalistic and
saved it from having to handle role comparisons.
As we introduce more features that need to distinguish between the
room owner and admins, refactor the token to carry the role
directly. The frontend can then derive the relevant flags from a
richer piece of information.
Add an endpoint that allows updating a user's role while in a
meeting. The goal is to let users promote other connected
participants to admin or moderator, so the burden of administrating
a meeting can be shared.
Introduce a new permission class that verifies the caller making a
request is both authenticated and actually present in the call.
It will be used to gate actions that require the user to be live in
the room, for example:
* allowing someone in from the waiting room
* promoting another participant to a different role
More generally, this covers every action where, for security
reasons, we need to make sure the user is truly present in the call
and that someone is not reusing their cookie as an API key.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
lebaudantoine