這篇主題有 1 篇回覆

[小島™]

此文件翻譯自doc/permissiondoc.txt，僅供參考並小心使用。

權限系統是非常多功能的，並且是一個豐富的系統特色，決定了哪些使用者可以進行哪些操作。

(布林權限) Boolean Permissions
-------------------
這些權限只有兩個值表示，true或false。

Example:
b_virtualserver_modify_name

從權限的名稱就可以立刻判斷這是一個布林權限，由 "b_" 作為開頭。
在這個前綴詞之後的是這個權限的實際名稱，可以幫助你理解這是個甚麼樣的權限。
在這個例子中，這個權限控制你是否可以改變虛擬伺服器的名稱
如果它被設定為"true"，你可以改變伺服器的名稱，如果這個權限被設為"false"或沒設立則反之。

(整數權限) Integer Permissions
-------------------
這些權限允許以整數來表示數值。

Examples:
i_channel_max_depth

從權限的名稱就可以立刻判斷這是一個整數權限，由 "i_" 作為開頭。
權限的實際名稱，channel_max_depth可以告訴你它是個怎麼樣的權限。
在這裡它可以控制設立頻道的深度有多少。
如果它被設為"0"，代表你指可以在最頂層設立頻道
如果它被設為"1"，你則可以建立個子頻道。設為"2"則可以在子頻道下開設子頻道，依此類推。

就如同許多權限沒有合理的數值限制，i_channel_max_depth可以設為"-1"這樣特殊的值作為表示沒有頻道最大深度的限制。

(權力及所需權力權限) Power and needed Power Permissions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
這些權限是整數權限的特例。
它們總是成對的，一則是權力而另一則所需權力權限
只有當你的權力大於等於所需的權力權限值時，你才可以成功的進行操作

Example:
i_client_kick_power
i_client_needed_kick_power

當你想要踢掉一個使用者時，權限系統將會比較你的 "kick power" 和目標使用者的 "needed kick power"。
當你有相當或更大的權力值時，你將可以踢掉這個使用者。
如果你的權力值小於所需的踢除權力值，你將無法進行此操作。
這基本上引入了"啄食順序(強弱順序-pecking order)"，例如你可以給較低階的管理人員踢除訪客的權限，但高階的管理人員則可以踢除任何在伺服器上的使用者。

(i_needed_modify_power_* 或 賦予權限) i_needed_modify_power_* or Grant-Permissions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
每一個權限都有一個相關的 i_needed_modify_power_ * 權限，例如 "PERMISSION_b_client_ban_create" 有一個關聯的權限稱為 "PERMISSION_i_needed_modify_power_client_ban_create"。
在客戶端的介面中，這些關聯的"needed_modify_power"權限通常顯示為附加在原有權限的"Grant(賦予）"值，而不是分開的權限，這就是為什麼我們也稱它為"Grant-Permissions(賦予權限)"。
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?
++++++++++++++++++++++++++++++++++++++++++++++++++++++
對於使用者取得權限的方式由五層的系統決定。
每一層可以覆蓋掉上一層的權限。
如果權限沒有被五層的任何一層所賦予，它將會假定為"0"或"false"值。
以下是五層列表：

第一層: 伺服器群組 (Server Groups)
第二層: 使用者個別的權限 (Client Specific Permissions)
第三層: 頻道個別的權限 (Channel Specific Permissions)
第四層: 頻道群組 (Channel Groups)
第五層: 頻道和使用者個別的權限 (Channel and Client Specific Permissions)

Example:
你在 (第一層)伺服器群組 "Guset" 中，這讓 b_channel_modify_name 權限被設為"fasle"。
但你也在 (第四層)頻道群組"Channel Admin" 並作為一個頻道管理員使 b_channel_modify_name 權限被設為"true"。
因為頻道群組比伺服器群組的層次還要高，所以你*可以*編輯頻道的名稱 (但不包含在其他不具有頻道管理員身分的頻道)。


現在我們將來仔細地討論每一層及每一層的特殊性質。

第一層: 伺服器群組
---------------------

(未完)

本篇文章已被 伝説のET 於 2010 年 01 月 11 日 - 下午 08:49 編輯過

[小島™]

原文

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 PERMISSION_b_client_ban_create has an
associated permission called PERMISSION_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 PERMISSION_i_permission_modify_power greater or equal to the Grant-Power for the concerned permission
of the editing client?
(3) When editing PERMISSION_i_group_modify_power, is the new value smaller or equal to the PERMISSION_i_group_modify_power of the
editing client?
(4) When editing PERMISSION_i_permission_modify_power, is the new value smaller or equal to the PERMISSION_i_permission_modify_power
of the editing client?
(5) When editing a PERMISSION_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 PERMISSION_i_group_modify_power greater or equal to the PERMISSION_i_group_needed_modify_power of
the group being edited?