← Dokumentacja

Uprawnienia

Boty otrzymują uprawnienia jako 53-bitowe całkowitoliczbowe pole bitowe w kształcie Discorda. Bity i ich znaczenie są zgodne z Discordem; wartości pochodzą z natywnych tabel uprawnień grup i kanałów GameVox. Bity bez odpowiednika w GameVox zwracają 0.

Mapowanie natywne → Discord

Bit Discorda	Hex	Źródło w GameVox
ADMINISTRATOR	0x8	groups.group_type IN ('owner', 'admin')
VIEW_CHANNEL	0x400	channel_permissions.view_channel / group_permissions.view_channels
READ_MESSAGE_HISTORY	0x10000	Tak samo jak VIEW_CHANNEL (brak osobnego przełącznika historii)
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	W v1 tylko dla administratorów
CONNECT (voice)	0x100000	join_voice
SPEAK	0x200000	speak_in_voice
STREAM (screen share)	0x200	screen_share
USE_VAD	0x2000000	use_vad (domyślnie true; ustawienie false wymusza PTT)
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, żadne nie jest ustawione na 'deny'
MANAGE_GUILD	0x20	edit_server != 'deny'
MANAGE_ROLES	0x10000000	manage_members
MANAGE_NICKNAMES	0x8000000	manage_members (w pakiecie z MANAGE_ROLES)
CHANGE_NICKNAME	0x4000000	Zawsze przyznane (zgodnie z domyślnym ustawieniem Discorda)
MANAGE_WEBHOOKS	0x20000000	Właściciel / administrator w v1
VIEW_AUDIT_LOG	0x80	Właściciel / administrator w v1
PRIORITY_SPEAKER	0x100	priority_speaker
MANAGE_EVENTS	0x200000000	manage_events != 'deny'
CREATE_EVENTS	0x100000000000	manage_events != 'deny' (w pakiecie z MANAGE_EVENTS)
MANAGE_GUILD_EXPRESSIONS	0x40000000	manage_emojis != 'deny'
CREATE_GUILD_EXPRESSIONS	0x80000000000	manage_emojis != 'deny' (w pakiecie)
DEAFEN_MEMBERS	0x800000	deafen_users != 'deny'
SEND_MESSAGES_IN_THREADS	0x4000000000	send_messages (w pakiecie z SEND_MESSAGES)

Bity domyślnie włączone

Są ustawione dla każdego członka bez odmowy, zgodnie z domyślnym zachowaniem roli na Discordzie. Jeśli logika twojego bota je sprawdza, zawsze będą wyglądały na przyznane (chyba że członek jest zbanowany):

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

Bity, które zawsze zwracają zero

Nie mają jeszcze odpowiednika w GameVox i są zgłaszane jako nieustawione. Boty, które od nich zależą, powinny łagodnie ograniczać funkcje (większość bibliotek i tak traktuje odmówiony bit jako „funkcja tutaj nieobsługiwana”).

• MANAGE_THREADS, USE_PUBLIC_THREADS, USE_PRIVATE_THREADS: wątki są w v1 tylko zaślepką.
• MODERATE_MEMBERS (timeout): brak natywnego odpowiednika.
• USE_EMBEDDED_ACTIVITIES: brak funkcji Activities.
• USE_SOUNDBOARD, SEND_VOICE_MESSAGES: niezaimplementowane.
• Bity monetyzacji: brak Premium Apps.

Obliczanie uprawnień

Identyczne jak 7-krokowy algorytm Discorda:

1. Zacznij od uprawnień @everyone dla gildii.
2. Dodaj (OR) każdą rolę, którą ma członek.
3. Jeśli wynik zawiera ADMINISTRATOR, zakończ: członek ma wszystko.
4. Zastosuj nadpisania kanału dla @everyone (najpierw zezwolenia, potem odmowy).
5. Zastosuj nadpisania kanału dla każdej roli (najpierw zezwolenia, potem odmowy).
6. Zastosuj nadpisania kanału dla użytkownika (najpierw zezwolenia, potem odmowy).
7. Jeśli kanał należy do kategorii, nadpisania kategorii również są stosowane na etapie ról / użytkownika.

Krok 2 to miejsce, w którym widać opisaną niżej różnicę: członek GameVox należy do jednej grupy, więc jest tylko jedna rola do dodania. Zobacz Jedna grupa na członka.

Jedna grupa na członka

To największa różnica w działaniu względem Discorda. Członek GameVox należy do dokładnie jednej grupy na serwerze, podczas gdy członek Discorda może mieć wiele ról naraz. Przypisanie grupy zastępuje grupę, w której członek był wcześniej.

Endpointy ról nadal działają, a biblioteki, których już używasz, nadal je wywołują. Po prostu sprowadzają się one do tej jednej grupy:

Wywołanie	Co się dzieje
PUT .../members/{id}/roles/{rid}	Członek trafia do tej grupy. Jego poprzednia grupa zostaje zastąpiona, a nie zachowana obok.
DELETE .../members/{id}/roles/{rid}	Usuwa grupę. Jeśli była to jego jedyna grupa, członek wraca do domyślnej grupy serwera, zamiast zostać bez żadnej.
PATCH .../members/{id} z roles: [...]	Akceptowane, a następnie sprowadzane do grupy o najwyższej randze z listy. Pusta lista oznacza grupę domyślną.

Lista jest sprowadzana, a nie odrzucana, żeby zwykłe member.roles.set([...]) nadal działało. Wygrywa najwyższa ranga, bo to ranga decyduje o pozycji: jeśli podasz grupę moderatorów i grupę z kolorem, członek będzie moderatorem.

Grupy mają limity wysyłania plików, głosu, kamery i udostępniania ekranu, a członek dostaje najhojniejszy limit spośród grup, do których należy. Przy jednej grupie jest to po prostu limit jego grupy. To drugi powód, dla którego aplikacja nie może trzymać kogoś w dwóch grupach: byłby to sposób na obejście limitu ustawionego przez operatora.

Nic z tego nie dotyczy własnej grupy aplikacji, czyli tej utworzonej przy instalacji. Jej członkostwo należy do instalacji i żadna aplikacja nie może się do niej dodać ani usunąć z niej innej aplikacji.

Hierarchia ról

Natywne groups.rank odpowiada role.position Discorda. Bot może zarządzać rolami wyłącznie poniżej pozycji swojej najwyższej roli, zgodnie z zasadami Discorda. Wywołania PATCH .../members/{id}/roles/{rid} z rolą na poziomie najwyższej roli bota lub wyżej zwracają 403.

Timeouty

Pole communication_disabled_until Discorda nie ma odpowiednika w GameVox v1. PATCH członka z ustawionym tym polem zwraca 400 z czytelnym komunikatem błędu. Zamiast tego użyj wyrzucenia, wyciszenia lub bana.

← Powrót do dokumentacji