Adding Groups (SourceMod) - Revision history

MisakaSora at 07:37, 12 September 2019

2019-09-12T07:37:26Z

Avi12 at 09:26, 2 April 2016

2016-04-02T09:26:00Z

Avi12: /* File Format */

2016-04-02T09:22:05Z

‎File Format

Peace-Maker at 22:42, 20 September 2012

2012-09-20T22:42:46Z

Peace-Maker at 20:04, 6 September 2012

2012-09-06T20:04:51Z

Recon0: /* File Format */

2009-03-18T21:52:33Z

‎File Format

Recon0: /* File Format */

2009-03-18T21:51:42Z

‎File Format

Recon0: /* File Format */

2009-03-18T21:50:32Z

‎File Format

BAILOPAN: added new article on group config

2007-09-10T15:09:07Z

added new article on group config

New page

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

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

The group blocks appear in this format:
<pre>
Groups
{
"Group Name"
{
"[option1]" "[value1]"
"[option2]" "[value2]"
/* ... */
Overrides
{
"[override1]" "[allow|deny]"
"[override2]" "[allow|deny]"
/* ... */
}
}
}
</pre>

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:
*<tt>flags</tt>: Flag string that users of the group will inherit.
*<tt>immunity</tt>: 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 <tt>sm_map</tt>. Conversely, you could opt to give members the "map" flag, but deny them access to <tt>sm_map</tt>.

Command groups are explained further in the [[Overriding Command Access (SourceMod)]] article.

Combined example of a group with overrides:
<pre>
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
}
}
}</pre>

=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 <tt>additive</tt>, meaning that they will be assumed if and only if they result in more permissions being granted.

For example, if a user has flags <tt>bcd</tt> and a group assigns flags <tt>ae</tt>, inheritance would result in that user having the flags <tt>abcde</tt>. 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 <tt>sm_reloadadmins</tt>, which effectively reloads all permissions anyway).

=See Also=
*[[Overriding Command Access (SourceMod)]]

[[Category:SourceMod Documentation]]

← Older revision		Revision as of 07:37, 12 September 2019
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 34: / Line 34: @@
 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>
 "Groups"

@@ Line 34: / Line 34: @@
 Command groups are explained further in the [[Overriding Command Access (SourceMod)]] article.
+== Combined example of a group with overrides: ==
 <pre>
 "Groups"

@@ Line 6: / Line 6: @@
 =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 [http://forums.alliedmods.net/showthread.php?t=81160 KVManager].
+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:

@@ Line 6: / Line 6: @@
 =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. Group configuration files can be created and modified with [http://forums.alliedmods.net/showthread.php?t=81160 KVManager].
+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 [http://forums.alliedmods.net/showthread.php?t=81160 KVManager].
 The group blocks appear in this format:

@@ Line 10: / Line 10: @@
 The group blocks appear in this format:
 <pre>
-Groups
+"Groups"
+{
 	"Group Name"
@@ Line 17: / Line 17: @@
 		"[option2]"	"[value2]"
 		/* ... */
-		Overrides
+		"Overrides"
+		{
 			"[override1]"	"[allow|deny]"
@@ Line 37: / Line 37: @@
 Combined example of a group with overrides:
 <pre>
-Groups
+"Groups"
+{
 	"Basic Admin"
@@ Line 44: / Line 44: @@
 		"immunity"		"1"	//low immunity value
-		Overrides
+		"Overrides"
+		{
 			"sm_map"	"allow"	//Let them use sm_map even without the flag

@@ Line 47: / Line 47: @@
+		{
 			"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
+		}
+	}