[TEAMSPEAK 3] The Permission System

ITALIANO ( tradotto da google ):

Il sistema di autorizzazione
================================================== ===

L’autorizzazione è un sistema molto versatile e ricco di funzionalità che determina quali
gli utenti sono autorizzati a fare le azioni.

Che tipo di autorizzazioni o ci sono?

Boolean Autorizzazioni

---

Queste autorizzazioni possono avere solo due valori, vero o falso.

Esempio:
b_virtualserver_modify_name

Dal nome della autorizzazione che si vede subito che è un permesso boolean, dal momento che
inizia con “b_”. Dopo questo prefisso è il nome effettivo del permesso, che dovrebbe dare
Sei un idea di quello che l’autorizzazione è di circa. In questo caso il permesso controlli sapere se è possibile
cambiare il nome del server virtuale. Se è impostata su true, è possibile modificare il nome del server virtuale,
se è impostato su false o non fissato a tutti non è possibile modificare il nome del server virtuale.

Integer Autorizzazioni

---

Questi permessi accettare come valori interi.

Esempi:
i_channel_max_depth

Dal nome di nuovo si può vedere che si tratta di un permesso intero, perché è prefisso
“I_”. Il nome effettivo del permesso, channel_max_depth in questo caso ti dice che cosa questo
permesso controlli. In questo caso si controlla quanto “profonda” strutture di canale che si possono creare. Così
se il valore è impostato su “0”, significa che si possono creare solo i canali di livello superiore. Se è impostato
a “1”, è anche possibile creare sub-canali. Impostare a “2” è anche possibile creare sub-sub-canali e così via.

Come per le autorizzazioni di molti che non hanno un limite logico i_channel_max_depth ha anche un valore speciale di “-1”
il che significa che non vi è alcuna limitazione massima profondità dei canali.

Potere e potenza necessarie autorizzazioni
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Queste autorizzazioni sono un caso speciale di autorizzazioni Integer. Sono sempre in coppia, una potenza di autorizzazione
e un bisogno di un permesso di potenza. È possibile solo questione con successo l’azione di controllo il permesso se il vostro
potenza è pari o superiore alla potenza associata necessario.

Esempio:

i_client_kick_power
i_client_needed_kick_power

Quando si vuole cacciare un cliente, il sistema di autorizzazione sarà confrontare il vostro “potere calcio” con il “potere calcio necessario”
del target del vostro calcio. Se si dispone di potenza uguale o maggiore, si sarà in grado di calciare questo client. Se il potere
è inferiore alla potenza necessaria calcio del bersaglio, non sarà in grado di passare attraverso. Questo introduce essenzialmente
una “gerarchia”, è possibile ad esempio concedere gli amministratori di livello inferiore il permesso di calcio solo gli ospiti, ma
amministratori di alto livello sono in grado di calcio di qualsiasi utente sul server.

i_needed_modify_power_ * o Grant-Autorizzazioni
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ogni autorizzazione è associato un permesso * i_needed_modify_power_, per esempio, ha un b_client_ban_create
autorizzazioni associati chiamato i_needed_modify_power_client_ban_create. In queste l’interfaccia client associati
autorizzazione needed_modify_power sono solitamente visualizzati come ulteriore valore “Grant” del permesso originale, invece di
come un permesso a parte propria, è per questo che noi chiamiamo queste autorizzazioni Grant-Autorizzazioni pure.
Queste controllo Grant-Autorizzazioni quali autorizzazioni è consentito a un client di concedere o revocare, in modo che siano la chiave per la modifica
il sistema di autorizzazione e sono quindi di solito riservati agli amministratori. Modifica del sistema di autorizzazione sarà spiegato
più in basso in un capitolo separato, chiamato “Chi può modificare il sistema dei permessi?”

Come fanno i client ottenere le autorizzazioni? Come sono assegnati?

Il modo in cui un client riceve i suoi permessi viene determinato attraverso un sistema di 5 strati. Ogni livello può sovrascrivere le autorizzazioni
dal livello precedente. Se il permesso non viene concesso a uno qualsiasi di questi 5 strati, si ipotizza essere di zero o false
di valore. Questi sono i 5 strati:

Tier 1: gruppi di server
Livello 2: Autorizzazioni specifiche del cliente
Livello 3: Le autorizzazioni specifico canale
Livello 4: gruppi di canali
Livello 5: Autorizzazioni al canale e specifiche del cliente

Esempio:
Tu sei nel gruppo di server “Guest” (Tier 1) che ha il permesso b_channel_modify_name impostata su false. Ma si sono anche
un “canale Admin” (Tier 4) e un canale amministratore ha b_channel_modify_name impostata su true. Poiché il gruppo canale è in una maggiore
secondo livello rispetto al gruppo di server, alla fine si * può * modificare il nome dei canali (ma non quella di altri canali in cui non si è
canale admin).

Ora discuteremo ogni livello ed è proprietà particolari nel dettaglio.

Tier 1: gruppi di server

---

Ogni cliente fa parte di uno o più gruppi di server. Questi gruppi di server può contenere qualsiasi numero di autorizzazioni, che si riceve
quando entrano a far parte del gruppo. Dal momento che si può essere parte di più gruppi di server in una sola volta, e dato che la stessa autorizzazione può
essere concesso in multipli di questi gruppi di server ci deve essere un modo per capire l’autorizzazione “risultante” dei Tier 1
strato in questi casi. La logica dietro questa è quella di utilizzare il valore più alto o meglio come risultato. Ogni permesso a un gruppo di server
può avere la “negazione” di bandiera o il “saltare” i flag impostati, saranno spiegati più avanti in questo capitolo. Dal momento che ogni cliente è sempre
parte di almeno un gruppo di server, c’è un gruppo speciale che può essere configurato nella configurazione del server, chiamata
“Gruppo di server predefinito”. Quando una nuova (in precedenza sconosciuto) si unisce al client server diventa automaticamente un membro di questo gruppo.
Anche se è attualmente il server predefinito in gruppo e ti viene assegnato un nuovo gruppo si esce automaticamente il server predefinito
Group.

Esempio:
Dire che sono membro di tre gruppi di server: Server Admin, Clan Leader e Guerra Organizer. Server Admin ha i_client_kick_power di 50.
Clan Leader ha i_client_kick_power del 100 e la seconda guerra Organizzatore non ha i_client_kick_power stabiliti a tutti. L’autorizzazione
risultante sul Tier 1 per voi è i_client_kick_power di 100, poiché questo è il valore più alto che avete a tutti i gruppi di server.

A volte si potrebbe desiderare di creare un gruppo di server che influenza negativamente gli utenti che sono messe in esso. Per esempio un “Sticky”
gruppo che non consente il passaggio di canali o di un gruppo “Silent” che rimuove i privilegi di parlare da parte dei clienti che ricevono
esso. Per consentire a questo negare la bandiera può essere aggiunto alle autorizzazioni in un gruppo di server. Se sei membro di un gruppo che ha un permesso
contrassegnato con la bandiera negare, non si riceverà il valore più alto di questa autorizzazione, ma piuttosto più basso che è contrassegnato con
negare.

Esempio:
È stato creato un gruppo di server chiamato “Sticky”. Contiene solo una autorizzazione: i_channel_join_power impostato su “-1”, ed una bandiera negare
viene applicato a questa autorizzazione. Ora, se mi concede gruppo appiccicoso a tutti i client non saranno in grado di cambiare canale più. Questo anche
funziona se l’utente che ho messo in gruppo “Sticky” ha una serie positiva i_channel_join_power, dal momento che la bandiera negare farà in modo che il Tier 1
risultato sarà il più basso i_channel_join_power autorizzazione negata, in modo da -1 o meno. Il motivo per cui non è possibile
Cambiare canale è più che normalmente un canale non ha impostato i_channel_needed_join_power, e se un permesso non è impostata
assunto pari a zero. Dal momento che -1 è minore di zero, l’utente non sarà in grado di aderire.

Dal momento che gruppi di server sono la prima serie di strati di autorizzazione, è possibile che vengano sovrascritti da un permesso di livello superiore.
Dal momento che a volte è opportuno evitare che gruppi di canali (livello 4) per sovrascrivere le autorizzazioni che si è ricevuto attraverso il Gruppo di server vostro
vi è la bandiera “Skip”. Se un permesso in entrambi i gruppi Server (Tier 1) o autorizzazioni specifiche del cliente (Tier 2), è il salto di bandiera,
questa autorizzazione non sarà alterato da alcuna autorizzazione sovrapposizione in gruppi di canali (Tier 4) Strato.

Esempio: Se l’amministratore del server non si desidera che il gruppo di canali per essere in grado di limitare le autorizzazioni. Con l’aggiunta del salto di bandiera di
tutte le autorizzazioni del gruppo di server admin è assicurarsi che non importa come sono configurate queste autorizzazioni da qualsiasi gruppi di canali
si può essere concesso, queste autorizzazioni canale di gruppo non avrà alcun effetto sulle vostre capacità.

Livello 2: Autorizzazioni specifiche del cliente

---

Questi permessi sono impostati su un client specifico, e sovrascrive tutte le autorizzazioni sovrapposizione del Tier 1. Autorizzazioni su questo livello
può anche (come Server autorizzazioni del gruppo) hanno il salto di bandiera che farà in modo che il gruppo di canali (livello 4) non sovrascrive i
valore di questa autorizzazione.

Esempio: vi trovate nella “Guest” Server Group, che ha una i_client_kick_power pari a zero. Dal momento che si vuole essere in grado di calciare senza assegnare
te di un gruppo di admin o simili, si è aggiunto uno specifico consenso del cliente i_client_kick_power con valore 100. Dal client specifico
Le autorizzazioni vengono Tier 2, che sovrascrive qualsiasi autorizzazioni Tier 1 si verifica quando si sovrappongono.

Livello 3: Le autorizzazioni specifico canale

---

Autorizzazioni canale specifico sono simili alle Autorizzazioni client specifico, ma applicata a un livello di canale. Un esempio di come
questo può essere usato è quello di controllare chi è autorizzato a parlare in un canale. È sufficiente impostare un valore i_client_needed_talk_power sul canale
e clienti solo con un permesso i_client_talk_power uguale o superiore sarà in grado di parlare in questo canale. Altri casi di utilizzo utile
potrebbero essere i canali che possono essere raggiunti da alcuni utenti (via i_channel_needed_join_power) o che non può che essere esaminata da alcuni
utenti (tramite i_channel_needed_subscribe_power). Tutte le autorizzazioni canale specifico che può logicamente essere applicata a un ambito canale sono
valido solo nell’ambito dei canali. Per esempio, se un permesso specifico canale ti dà un valore elevato i_client_kick_power, è possibile
usare solo questo per dare il client che sono in questo canale, non i clienti che si trovano in altri canali. Naturalmente alcune autorizzazioni non hanno
portata canale logico da poter essere applicato, per esempio b_virtualserver_stop – questo non funziona esattamente come se fossero
concesso ad esempio tramite un gruppo di server.

Livello 4: gruppi di canali

---

Ogni cliente fa parte di esattamente un gruppo di canali. Quando un client viene inserito in un gruppo nuovo canale, il server rimuove automaticamente
questo client dal gruppo canale precedente. Tutte le autorizzazioni si ottiene attraverso un gruppo di canali può essere applicato solo sulla
livello di canale, per esempio se si sono concessi b_channel_modify_password sarà solo consentono di modificare la password del canale
in cui effettivamente dispongono di questa autorizzazione. Ci sono due gruppi di canali speciali che sono configurati nelle impostazioni divide, la
“Default Channel Group” è assegnato a qualsiasi cliente che entra in un canale per la prima volta e il “Default Channel Admin Group” è
concesso al client che crea un canale.

Livello 5: Autorizzazioni al canale e specifiche del cliente

---

Autorizzazioni al canale e specifiche del cliente sono come una combinazione di autorizzazioni specifiche del cliente (Tier 2) e autorizzazioni specifico canale
(Tier 3). Esse si applicano a un client e un canale alla volta, solo quando il client specificato ed i canali di cui sono interessati non hanno
abbiano effetto. Questo è utilizzato dal client per la funzionalità degli altoparlanti priorità: quando si è concesso speaker stato di priorità, un canale e
autorizzazione specifica del cliente viene aggiunto per il cliente e il canale corrente sei (b_client_is_priority_speaker chiamato). Come con Tier 3
Tier 4 e tutte le autorizzazioni che possono essere logicamente applicato ad un ambito canale sarà valida solo all’interno di canali in cui hai questa autorizzazione
concesso.

Chi può modificare il sistema dei permessi?

Il sistema di autorizzazione decide anche chi ha il permesso di modificare il sistema di autorizzazione stessa, di solito un compito che solo gli amministratori saranno
di fiducia con.

Creazione e rimozione di gruppi

---

Per creare un gruppo di server, sarà necessario il permesso b_virtualserver_servergroup_create.
Per eliminare un gruppo di server, sarà necessario il permesso b_virtualserver_servergroup_delete.
Per creare un gruppo di canali, sarà necessario il permesso b_virtualserver_channelgroup_create.
Per eliminare un gruppo di canali, sarà necessario il permesso b_virtualserver_channelgroup_delete.

Aggiunta e rimozione di clienti da / per gruppi

---

Per aggiungere un client in un server o gruppo di canali è necessario un valore che i_group_member_add_power
è maggiore o uguale alla i_group_needed_member_add_power del gruppo specifico. Analogamente
avrete bisogno di un i_group_member_remove_power che è maggiore o uguale al
i_group_needed_member_remove_power del gruppo specifico.

Aggiunta, rimozione e modifica di autorizzazioni

---

Tutte le seguenti domande è necessario rispondere con “Sì” quando aggiunta, rimozione o modifica di una autorizzazione per qualsiasi livello:
(1) Se il client di editing, ha un Grant di alimentazione per l’autorizzazione concerened con un valore che non è zero?
(2) è il client di editing i_modify_power maggiore o uguale al-Grant Power per l’autorizzazione in questione
del client di editing?
(3) Quando i_group_modify_power modifica, è il nuovo valore minore o uguale a quello del i_group_modify_power
editing cliente?
(4) Quando i_modify_power modifica, è il nuovo valore minore o uguale al i_modify_power
del client di editing?
(5) Quando la modifica di un permesso * i_needed_modify_power_ (chiamato anche Grant-permesso), è il nuovo valore minore o uguale a
i clienti di editing Grant-Potenza del permesso in questione?

Inoltre, quando i gruppi di server modifica o gruppi di canali il seguente è verificata anche:
– Il client di editing i_group_modify_power maggiore o uguale a quello di i_group_needed_modify_power
il gruppo in fase di modifica?

Auto-Aggiornamento delle autorizzazioni

---

Ogni volta che il permesso di sistema viene aggiornato, il server cercherà automaticamente di assegnare le nuove autorizzazioni per i gruppi esistenti.
Per abilitare l’auto-aggiornamento, è sufficiente aggiungere un valore per i_group_auto_update_type del gruppo target. I seguenti valori sono
disponibili:

Valore 0: Il gruppo sarà gestito come ‘Query Guest’
Valore 1: Il gruppo sarà gestito come ‘Query Amministratore’
Valore 2: Il gruppo sarà gestito come ‘Server Admin’
Valore 3: Il gruppo sarà gestito come ‘normale server’
Valore 4: Il gruppo sarà gestito come ‘Guest Server’
Valore 5: Il gruppo sarà gestito come ‘canale Amministratore’
Valore 6: Il gruppo sarà gestito come ‘canale’ operatore
Valore 7: Il gruppo sarà gestito come ‘Channel Voice’
Valore 8: Il gruppo sarà gestito come ‘canale Guest’

Come potete vedere, ciascuno di questi valori rappresenta un gruppo dal permesso di default del Server 3 TeamSpeak. Per esempio, se
il permesso di sistema viene aggiornato con una nuova autorizzazione per Server Admin, tutti i gruppi che hanno la loro i_group_auto_update_type
impostato su 2 sarà aggiornato automaticamente.

ENGLISH

---

The Permission System
================================================== ===
The Permission System is a very versatile and feature rich system that determines which
users are allowed to do which actions.
What kind or permissions are there?

Boolean Permissions

---

These permissions can only have two values, true or false.
Example:
b_virtualserver_modify_name
From the name of the permission you immediately see that it a boolean permission, since it
begins with “b_”. After this prefix is the actual name of the permission, which should give
you an idea what the permission is about. In this case the permission controls if you may
change the virtual server name. If it is set to true, you can change the virtual server name,
if it is set to false or not set at all you can not edit the virtual server name.
Integer Permissions

---

These permissions accept integers as values.
Examples:
i_channel_max_depth
From the name again you can see that it is an integer permission, because it is prefixed with
“i_”. The actual name of the permission, channel_max_depth in this case tells you what this
permission controls. In this case it controls how “deep” channel structures you may create. So
if the value is set to “0”, it means you can create only top-level channels. If it is set
to “1”, you can also create sub-channels. Set to “2” you can also create sub-sub-channels and so on.
As with many permissions that have no logical limit i_channel_max_depth also has a special value of “-1”
which means there is no maximum depth limitation for channels.
Power and needed Power Permissions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
These permissions are a special case of Integer Permissions. They always come in pairs, one power permission
and one needed power permission. You can only successfully issue the action the permission controls if your
power is equal or greater than the associated needed power.
Example:
i_client_kick_power
i_client_needed_kick_power
When you want to kick a client the permission system will compare your “kick power” with the “needed kick power”
of the target of your kick. If you have equal or greater power, you will be able to kick this client. If your power
is less than the needed kick power of your target, you will not be able to go through. This essentially introduces
a “pecking order”, you can for example grant your lower tier administrators the permission to kick only guests, but
your high tier administrators are able to kick any user on the server.
i_needed_modify_power_* or Grant-Permissions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Every permission has an associated i_needed_modify_power_* permission, for example b_client_ban_create has an
associated permission called i_needed_modify_power_client_ban_create. In the client interface these associated
needed_modify_power permission are usually displayed as additional “Grant” value of the original permission, instead of
as a separate permission of its own, which is why we call these permissions Grant-Permissions as well.
These Grant-Permissions control which permissions a client is allowed to grant or revoke, so they are the key to modifying
the permission system and are thus usually reserved to administrators. Editing the permission system will be explained
further down in a separate chapter called “Who can edit the permission system?”
How do clients get permissions? How are they assigned?

The way a client receives his permissions is determined through a 5 layer system. Each layer can overwrite permissions
from the previous layer. If a permission is not granted on any of these 5 layers, it will be assumed to be of zero or false
value. These are the 5 Layers:
Tier 1: Server Groups
Tier 2: Client Specific Permissions
Tier 3: Channel Specific Permissions
Tier 4: Channel Groups
Tier 5: Channel and Client Specific Permissions
Example:
You are in the “Guest” server group (Tier 1) which has the permission b_channel_modify_name set to false. But you are also
a “Channel Admin” (Tier 4) and a channel admin has b_channel_modify_name set to true. Since the channel group is in a higher
tier than the server group, in the end you *can* modify your channels name (but not that of other channels where you are not
channel admin).
Now we will discuss each layer and it’s special properties in detail.
Tier 1: Server Groups

---

Every client is part of one or more server groups. These server groups can contain any number of permissions, that you receive
when becoming part of the group. Since you can be part of multiple Server Groups at once, and since the same permission could
be granted in multiple of these Server Groups there has to be a way to figure out the “resulting” permission of the Tier 1
layer in these cases. The logic behind this is to use the best or highest value as result. Every permission in a Server Group
can have the flag “negate” or the “skip” flags set, they will be explained later in this chapter. Since every client is always
part of at least one server group, there is a special group that can be configured in the server configuration, called the
“Default Server Group”. When a new (previously unknown) client joins the server he automatically becomes a member of this group.
Also if you are currently in the Default Server Group and you are assigned a new group you automatically leave the Default Server
Group.
Example:
Say you are member of three Server Groups: Server Admin, Clan Leader and War Organizer. Server admin has i_client_kick_power of 50.
Clan Leader has i_client_kick_power of 100 and War Organizer does not have i_client_kick_power set at all. The permission
resulting on Tier 1 for you is i_client_kick_power of 100, since this is the highest value you have from all your server groups.
Sometimes you might want to create a Server Group that negatively affects the users that are put into it. For example a “Sticky”
group that disallows switching of channels or a “Silent” group that removes the privileges to talk from the clients that receive
it. To allow this the negate flag can be added to permissions in a server group. If you are member of a group that has a permission
flagged with the negate flag, you will not receive the highest value of this permission, but rather the lowest that is flagged with
negate.
Example:
You created a Server Group called “Sticky”. It contains only one permission: i_channel_join_power set to “-1”, and a negate flag
is applied to this permission. Now if I grant sticky group to any client they will not be able to switch channels anymore. This also
works if the user I put into “Sticky” group has a positive i_channel_join_power set, since the negate flag will make sure the Tier 1
result will be the lowest negated i_channel_join_power permission, so -1 or less than that. The reason why it is not possible to
switch channels anymore is that normally a channel has no i_channel_needed_join_power set, and if a permission is not set it is
assumed to be zero. Since -1 is smaller than zero, the user won’t be able to join.
Since Server Groups are the first Tier of permission layers, it is possible that they will be overwritten by a higher tier permission.
Since it is sometimes desirable to prevent Channel Groups (Tier 4) to overwrite permissions that you received through your Server Group
there is the “Skip” flag. If a permission in either Server Group (Tier 1) or Client Specific Permissions (Tier 2) has the skip flag set,
this permission will not be altered by any overlapping permission in the Channel Groups (Tier 4) layer.
Example: As the admin of your server you do not want the channel group to be able to restrict your permissions. By adding the skip flag to
all of the permissions in the server admin group you make sure that no matter how these permissions are configured by any channel groups
you may be granted, these channel group permissions will not take any effect on your abilities.
Tier 2: Client Specific Permissions

---

These permission are set to a specific client, and they will overwrite any overlapping permissions from Tier 1. Permissions on this layer
can also (like Server Group permissions) have the skip flag set which will make sure the Channel Group (Tier 4) will not overwrite the
value of this permission.
Example: You are in the “Guest” Server Group, which has a i_client_kick_power of zero. Since you want to be able to kick without assigning
yourself an admin group or similar, you added a client specific permission of i_client_kick_power with value 100. Since Client Specific
Permissions are Tier 2, they will overwrite any Tier 1 permissions when overlap occurs.
Tier 3: Channel Specific Permissions

---

Channel Specific Permissions are similar to the Client Specific Permissions, but applied on a channel level. One example of how
this can be used is to control who is allowed to talk in a channel. Simply set a i_client_needed_talk_power value on the channel
and only clients with a equal or higher i_client_talk_power permission will be able to talk in this channel. Other useful use cases
might be channels that can only be joined by some users (via i_channel_needed_join_power) or that can only be looked into by some
users (via i_channel_needed_subscribe_power). All channel specific permissions that can logically be applied to a channel scope are
only valid within the channel scope. For example if a channel specific permission gives you a high i_client_kick_power value, you can
only use this to kick clients that are in this channel, not clients that are in other channels. Of course some permissions have no
logical channel scope they can be applied to, for example b_virtualserver_stop – these will work exactly the same as if they were
granted e.g. via a Server Group.
Tier 4: Channel Groups

---

Every client is part of exactly one channel group. When a client is inserted into a new channel group, the server automatically removes
this client from the previous channel group. All permissions you get via a channel group can only be applied on the
channel level, for example if you are granted b_channel_modify_password it will only let you modify the password of the channel
in which you actually have this permission. There are two special channel groups that are configured in the sever settings, the
“Default Channel Group” is assigned to any client that joins a channel for the first time and the “Default Channel Admin Group” is
granted to the client that creates a channel.
Tier 5: Channel and Client Specific Permissions

---

Channel and Client Specific Permissions are like a combination of Client Specific Permissions (Tier 2) and Channel Specific Permissions
(Tier 3). They apply to a client and a channel at once; only when the specified client and the specified channels are concerned do they
take affect. This is used by the client for the priority speaker feature: when you are granted priority speaker status, a channel and
client specific permission is added for your client and the current channel you are (called b_client_is_priority_speaker). As with Tier 3
and Tier 4 all permissions that can logically be applied to a channel scope will only be valid within channels where you have this permission
granted.
Who can edit the permission system?

The permission system also decides who is allowed to edit the permission system itself, usually a task that only administrators will be
trusted with.
Creating and Removing Groups

---

To create a server group, you will need the b_virtualserver_servergroup_create permission.
To delete a server group, you will need the b_virtualserver_servergroup_delete permission.
To create a channel group, you will need the b_virtualserver_channelgroup_create permission.
To delete a channel group, you will need the b_virtualserver_channelgroup_delete permission.
Adding and Removing Clients to/from Groups

---

To add a client into a server or channel group you need a i_group_member_add_power value that
is greater or equal than the i_group_needed_member_add_power of the specific group. Analogously
you will need a i_group_member_remove_power that is greater or equal to the
i_group_needed_member_remove_power of the specific group.
Adding, Removing and Editing Permissions

---

All of the following questions need to be answered with “Yes” when adding, removing or editing a permission on any layer:
(1) Does the editing client have a Grant-Power for the concerened permission with a value that is not zero?
(2) Is the editing clients i_modify_power greater or equal to the Grant-Power for the concerned permission
of the editing client?
(3) When editing i_group_modify_power, is the new value smaller or equal to the i_group_modify_power of the
editing client?
(4) When editing i_modify_power, is the new value smaller or equal to the i_modify_power
of the editing client?
(5) When editing a i_needed_modify_power_* permission (also called Grant-Permission), is the new value smaller or equal to
the editing clients Grant-Power of the permission in question?
Additionally, when editing Server Groups or Channel groups the following is also checked:
– Is the editing clients i_group_modify_power greater or equal to the i_group_needed_modify_power of
the group being edited?

Auto-Updating Permissions

---

Whenever the Permission System gets updated, the server will automatically try to assign the new permissions to your existing groups.
To enable auto-updating, simply add a value for i_group_auto_update_type of the target group. The following values are
available:
Value 0: The group will be handled like ‘Query Guest’
Value 1: The group will be handled like ‘Query Admin’
Value 2: The group will be handled like ‘Server Admin’
Value 3: The group will be handled like ‘Server Normal’
Value 4: The group will be handled like ‘Server Guest’
Value 5: The group will be handled like ‘Channel Admin’
Value 6: The group will be handled like ‘Channel Operator’
Value 7: The group will be handled like ‘Channel Voice’
Value 8: The group will be handled like ‘Channel Guest’
As you can see, each of these values represents a group from the default permission set of the TeamSpeak 3 Server. For example, if
the Permission System is updated with a new permission for Server Admins, all groups having their i_group_auto_update_type
set to 2 will be updated automatically.