Difference between revisions of "Adding Groups (SourceMod)"

From AlliedModders Wiki
Jump to: navigation, search
(added new article on group config)
 
m
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
{{Languages|Adding_Groups (SourceMod)}}
 +
__FORCETOC__
 +
 
This article explains how to add and configure groups through <tt>configs/admin_groups.cfg</tt>.  This file is parsed and loaded via <tt>admin-flatfile.smx</tt>.
 
This article explains how to add and configure groups through <tt>configs/admin_groups.cfg</tt>.  This file is parsed and loaded via <tt>admin-flatfile.smx</tt>.
  
Line 6: Line 9:
  
 
=File Format=
 
=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.
+
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 <tt>admin_groups.cfg</tt> files with [http://forums.alliedmods.net/showthread.php?t=81160 KVManager].
  
 
The group blocks appear in this format:
 
The group blocks appear in this format:
 
<pre>
 
<pre>
Groups
+
"Groups"
 
{
 
{
 
"Group Name"
 
"Group Name"
Line 17: Line 20:
 
"[option2]" "[value2]"
 
"[option2]" "[value2]"
 
/* ... */
 
/* ... */
Overrides
+
"Overrides"
 
{
 
{
 
"[override1]" "[allow|deny]"
 
"[override1]" "[allow|deny]"
Line 34: Line 37:
  
 
Command groups are explained further in the [[Overriding Command Access (SourceMod)]] article.
 
Command groups are explained further in the [[Overriding Command Access (SourceMod)]] article.
 
+
=== Combined example of a group with overrides: ===
Combined example of a group with overrides:
 
 
<pre>
 
<pre>
Groups
+
"Groups"
 
{
 
{
 
"Basic Admin"
 
"Basic Admin"
Line 44: Line 46:
 
"immunity" "1" //low immunity value
 
"immunity" "1" //low immunity value
  
Overrides
+
"Overrides"
 
{
 
{
 
"sm_map" "allow" //Let them use sm_map even without the flag
 
"sm_map" "allow" //Let them use sm_map even without the flag
":CSDM" "deny" //deny any commands from the CSDM group
+
"@CSDM" "deny" //deny any commands from the CSDM group
 
}
 
}
 
}
 
}

Latest revision as of 02:37, 12 September 2019

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.

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).


See Also