Registered users

A registered user is one who has tied their certificate to a specific username on your server. Registered users can:

• Always log in with the same name (no impersonation).
• Receive roles.
• Get specific permissions in ACLs.
• Persist things like a per-server bio.

This page covers the Registered users tab in the admin panel.

 Screenshot placeholder: registered users tab listing eight users with role badges.

Register a user

There are two flows.

Self-registration (user asks)

The user right-clicks their own name in the user list and picks Register. Depending on your settings, this either:

• Auto-approves (default for many servers).
• Queues for admin approval.

Configure the gate with:

environment:
  MUMBLE_CONFIG_ALLOWREGISTRATION: true
  MUMBLE_CONFIG_REGISTRATIONREQUIRESAPPROVAL: false

Admin-initiated

You can register a user even if they have not asked:

1. Right-click the user in the user list, Register.
2. Confirm the username.
3. The certificate is bound to that name.

Manage from the admin panel

Open Admin, Users. You get a searchable table with:

• Name.
• Last seen (date).
• Registered on.
• Roles (badges).
• Email (optional, set by the user).
• Comment.

Per-row actions:

• Edit: change the display name and email.
• Manage roles: assign and revoke roles.
• Change password: only if the user uses password auth (rare).
• Force-deregister: removes the binding. Their certificate becomes unrecognized.
• Kick: disconnect now, no permanent effect.
• Ban: see Ban list.

Bulk import

You can populate registered users from a CSV. Useful when migrating from another platform.

name,email,certificate_hash
alice,alice@example.com,SHA1:1234...
bob,bob@example.com,SHA1:5678...

Import from Admin, Users, Import. Each row creates a registered user. The certificate hash binds it to a real user as soon as they connect.

Display names

Registered users can pick a display name that differs from their username. The username is the unique key (used in ACLs); the display name is what other users see in the sidebar.

Combine with name styles for fun.

Per-user permissions

You can give a permission to one user without making a role:

1. Edit the channel where the permission applies.
2. ACL tab, Add rule.
3. Pick the user from the dropdown (not a group).
4. Pick the permission and Allow or Deny.

This is fine for a one-off, but prefer roles for anything that might apply to more than one person.

Searching

The user table supports:

• Free text in the search box (name, email, comment).
• Filter by role: pick from the dropdown.
• Sort by clicking column headers.

Removing a user

Two distinct operations:

• Deregister: removes the certificate binding. The user can reconnect anonymously or under a new name.
• Ban: see Ban list.

You usually want Ban plus Deregister for a permanent removal.

Priority speaker

Any admin with the Mute/Deafen permission can right-click a user and toggle Priority speaker on or off.

When a user has priority status:

• All other users in the same channel are automatically attenuated (turned down) while the priority speaker is transmitting.
• A megaphone icon appears next to their name in the sidebar.
• The effect is temporary. It lasts until you remove it or the user disconnects.

This is useful for moderators, presenters, or a team lead speaking over a group channel where background crosstalk is disruptive.

To toggle: right-click the user → Admin section → Priority speaker / Remove priority.

Idle time

Every user entry shows an idle time counter. This tracks inactivity within Mumble, not on the desktop, for privacy reasons.

Actions that reset the counter:

• Any status change (mute, deafen, change channel, etc.)
• Speaking
• Opening the channel edit dialog

Actions that do not reset the counter:

• Viewing another user’s profile
• Reading channel descriptions or user comments
• Opening a right-click context menu
• Sending a message (counter resets only when OK is clicked, not when the chat window opens)

The counter intentionally reflects Mumble-specific activity. Deliberately resetting it by desktop interaction would be a privacy violation.

Pitfalls

• Cannot find a user: they may not be registered. Anonymous users only show in the live user list, not the admin table.
• User has no roles: that is the default. Assign at least one role to give them any non-default permissions.
• “This username is already taken”: someone else owns the username. Names are unique.

Next step

Continue with Roles & permissions.