← Docs

Permissions

Les bots reçoivent les permissions sous la forme d’un champ de bits entier 53 bits au format Discord. Les bits et leur signification correspondent à Discord ; les valeurs proviennent des tables natives de permissions de groupe et de salon de GameVox. Les bits sans équivalent GameVox renvoient 0.

Correspondance natif → Discord

Bit Discord	Hex	Source GameVox
ADMINISTRATOR	0x8	groups.group_type IN ('owner', 'admin')
VIEW_CHANNEL	0x400	channel_permissions.view_channel / group_permissions.view_channels
READ_MESSAGE_HISTORY	0x10000	Comme VIEW_CHANNEL (pas d’interrupteur d’historique distinct)
SEND_MESSAGES	0x800	send_messages
MANAGE_MESSAGES	0x2000	manage_messages
EMBED_LINKS	0x4000	can_post_links
ATTACH_FILES	0x8000	send_files
ADD_REACTIONS	0x40	add_reactions
MENTION_EVERYONE	0x20000	Réservé aux admins en v1
CONNECT (voice)	0x100000	join_voice
SPEAK	0x200000	speak_in_voice
STREAM (screen share)	0x200	screen_share
USE_VAD	0x2000000	use_vad (true par défaut ; à false, force le push-to-talk)
KICK_MEMBERS	0x2	kick_users != 'deny'
BAN_MEMBERS	0x4	ban_users != 'deny'
MUTE_MEMBERS	0x400000	mute_users != 'deny'
MOVE_MEMBERS	0x1000000	move_users != 'deny'
MANAGE_CHANNELS	0x10	create_channels / edit_channels / delete_channels tous différents de 'deny'
MANAGE_GUILD	0x20	edit_server != 'deny'
MANAGE_ROLES	0x10000000	manage_members
MANAGE_NICKNAMES	0x8000000	manage_members (groupé avec MANAGE_ROLES)
CHANGE_NICKNAME	0x4000000	Toujours accordé (comme la valeur par défaut de Discord)
MANAGE_WEBHOOKS	0x20000000	Propriétaire / admin en v1
VIEW_AUDIT_LOG	0x80	Propriétaire / admin en v1
PRIORITY_SPEAKER	0x100	priority_speaker
MANAGE_EVENTS	0x200000000	manage_events != 'deny'
CREATE_EVENTS	0x100000000000	manage_events != 'deny' (groupé avec MANAGE_EVENTS)
MANAGE_GUILD_EXPRESSIONS	0x40000000	manage_emojis != 'deny'
CREATE_GUILD_EXPRESSIONS	0x80000000000	manage_emojis != 'deny' (groupé)
DEAFEN_MEMBERS	0x800000	deafen_users != 'deny'
SEND_MESSAGES_IN_THREADS	0x4000000000	send_messages (groupé avec SEND_MESSAGES)

Bits activés par défaut

Ils sont positionnés pour tout membre non refusé, comme le rôle par défaut de Discord. Si la logique de votre bot les vérifie, ils apparaîtront toujours comme accordés (sauf si la personne est bannie) :

• CREATE_INSTANT_INVITE (0x1)
• USE_APPLICATION_COMMANDS (0x80000000)
• USE_EXTERNAL_EMOJIS (0x40000)
• USE_EXTERNAL_STICKERS (0x2000000000)

Bits qui renvoient toujours zéro

Ils n’ont pas encore d’équivalent sur GameVox et sont signalés comme non positionnés. Les bots qui en dépendent doivent se dégrader proprement (la plupart des bibliothèques traitent déjà un bit refusé comme « fonctionnalité indisponible ici »).

• MANAGE_THREADS, USE_PUBLIC_THREADS, USE_PRIVATE_THREADS : les fils sont à l’état d’ébauche en v1.
• MODERATE_MEMBERS (timeout) : pas d’équivalent natif.
• USE_EMBEDDED_ACTIVITIES : pas de fonctionnalité Activités.
• USE_SOUNDBOARD, SEND_VOICE_MESSAGES : non implémentés.
• Bits de monétisation : pas de Premium Apps.

Calcul des permissions

Identique à l’algorithme en 7 étapes de Discord :

1. Partez des permissions @everyone de la guild.
2. Faites un OU logique avec chaque rôle du membre.
3. Si le résultat contient ADMINISTRATOR, on s’arrête : tout est accordé.
4. Appliquez les exceptions de salon de @everyone (allow puis deny).
5. Appliquez les exceptions de salon de chaque rôle (allow puis deny).
6. Appliquez les exceptions de salon de la personne (allow puis deny).
7. Si le salon est dans une catégorie, les exceptions de celle-ci s’appliquent aussi aux étapes rôle et personne.

C’est à l’étape 2 qu’apparaît la différence ci-dessous : un membre GameVox est dans un seul groupe, il n’y a donc qu’un rôle à combiner. Voir Un groupe par membre.

Un groupe par membre

La plus grande différence de comportement avec Discord. Un membre GameVox appartient à exactement un groupe par serveur, là où un membre Discord peut cumuler plusieurs rôles. Attribuer un groupe remplace celui du membre.

Les endpoints de rôle fonctionnent toujours, et les bibliothèques que vous utilisez déjà continuent de les appeler — ils se résolvent simplement vers cet unique groupe :

Appel	Ce qui se passe
PUT .../members/{id}/roles/{rid}	Le membre se retrouve dans ce groupe. Son groupe précédent est remplacé, pas conservé à côté.
DELETE .../members/{id}/roles/{rid}	Le retire. Si c’était son seul groupe, il bascule vers le groupe par défaut du serveur au lieu de n’en avoir aucun.
PATCH .../members/{id} avec roles: [...]	Accepté, puis réduit au groupe de plus haut rang de la liste. Une liste vide signifie le groupe par défaut.

Une liste est réduite plutôt que refusée pour qu’un member.roles.set([...]) ordinaire continue de fonctionner. Le rang le plus élevé l’emporte parce que c’est lui qui détermine le statut : entre un groupe de modération et un groupe de couleur, le membre est modérateur.

Les groupes portent des plafonds de téléversement, de vocal, de caméra et de partage d’écran, et un membre obtient le plafond le plus généreux des groupes auxquels il appartient. Avec un seul groupe, c’est simplement celui de son groupe — c’est l’autre raison pour laquelle une app ne peut pas placer quelqu’un dans deux groupes : ce serait un moyen de dépasser un plafond fixé par l’administration.

Le groupe propre à une application — celui que son installation a créé — n’est concerné par rien de tout cela. Son appartenance relève de l’installation, et aucune app ne peut s’y ajouter ni en retirer une autre.

Hiérarchie des rôles

Le groups.rank natif correspond au role.position de Discord. Un bot ne peut gérer que les rôles strictement en dessous de la position de son rôle le plus élevé, comme sur Discord. Les appels à PATCH .../members/{id}/roles/{rid} avec un rôle égal ou supérieur au rôle le plus haut du bot renvoient 403.

Timeouts

Le champ communication_disabled_until de Discord n’a pas d’équivalent GameVox en v1. Un PATCH sur un membre avec ce champ renvoie 400 avec une erreur explicite. Utilisez plutôt l’expulsion, la mise en sourdine ou le bannissement.

← Retour à la documentation