Adding Groups (SourceMod)
| Language: | English • 中文 |
|---|
This article explains how to add and configure groups through configs/admin_groups.cfg. This file is parsed and loaded via admin-flatfile.smx.
Contents
Introduction
Groups are a convenient method of applying similar properties and permissions to multiple administrators. For example, let's say you wish for 15 administrators to all have the same permissions and immunity. In this case, you'd set up a group for these admins, after which changing the permissions for all member admins can be done via one location.
File Format
Groups are specified as blocks within a master "Group" block. Each group must have a unique name. If the name is not unique, the permissions will simply be extended/overwritten from the permissions of the existing group. That is to say, if a group exists in both the config file and an external source (say, SQL), then the permissions will end up being combined/overwritten in the order of parsing. You can create and / or modify admin_groups.cfg files with KVManager.
The group blocks appear in this format:
"Groups"
{
"Group Name"
{
"[option1]" "[value1]"
"[option2]" "[value2]"
/* ... */
"Overrides"
{
"[override1]" "[allow|deny]"
"[override2]" "[allow|deny]"
/* ... */
}
}
}
All options are optional (that is, they do not need to be explicitly defined). Similarly, the "Overrides" section is completely optional and may be omitted. The full options list contains:
- flags: Flag string that users of the group will inherit.
- immunity: If a numerical value, specifies the immunity value users will inherit if higher than their current immunity value. If preceded by an '@' symbol, then it specifies a group that the user will always be immune from.
The "Overrides" section allows specific commands or groups of commands to be completely allowed or denied to members of the group. This is a very powerful section. For example, you can opt to not give members the "map" flag, but allow them access to sm_map. Conversely, you could opt to give members the "map" flag, but deny them access to sm_map.
Command groups are explained further in the Overriding Command Access (SourceMod) article.
Combined example of a group with overrides:
"Groups"
{
"Basic Admin"
{
"flags" "abc" //reservation, generic admin, kick
"immunity" "1" //low immunity value
"Overrides"
{
"sm_map" "allow" //Let them use sm_map even without the flag
"@CSDM" "deny" //deny any commands from the CSDM group
}
}
}
Inheritance
Groups cannot be nested; that is to say, one group cannot inherit permissions from another group. However, an administrator can inherit any number of groups. The permissions will be additive, meaning that they will be assumed if and only if they result in more permissions being granted.
For example, if a user has flags bcd and a group assigns flags ae, inheritance would result in that user having the flags abcde. Similarly, a group's immunity value will only be inherited if it is larger than the user's current immunity value.
The only case this changes is with group-specific overrides. If a command is specifically allowed to group A and denied in group B, and a user inherits both groups A and B, whether or not the user can use the command will depend on the order of inheritance. If A is inherited first, the command will be allowed. If B is inherited first, the command will be denied.
Lastly, it is worth noting that once a user inherits permissions from a group, changes to the group will not affect the active permissions. This is an optimization. In order for changes to groups to affect that user, their administrative permissions must be entirely reset (either by a disconnect, or via sm_reloadadmins, which effectively reloads all permissions anyway).
