Admin API (SourceMod) - Revision history

Luki1412: Added admcache command

2026-10-24T20:40:06Z

Added admcache command

Kilandor: Undo revision 7777 by Kilandor (Talk) - I was completley wrong

2010-07-18T01:28:05Z

Undo revision 7777 by Kilandor (Talk) - I was completley wrong

Kilandor: /* Admin Flags */ added list of flags, since they are not found in api, and require digging into source files

2010-07-18T01:06:34Z

‎Admin Flags: added list of flags, since they are not found in api, and require digging into source files

BAILOPAN at 19:20, 19 January 2008

2008-01-19T19:20:44Z

BAILOPAN at 00:17, 16 November 2007

2007-11-16T00:17:59Z

BAILOPAN at 14:18, 10 September 2007

2007-09-10T14:18:02Z

BAILOPAN: new immunity rules

2007-09-10T14:16:11Z

new immunity rules

DS: Fixed category

2007-02-06T21:38:11Z

Fixed category

BAILOPAN at 09:00, 6 February 2007

2007-02-06T09:00:18Z

BAILOPAN at 08:38, 6 February 2007

2007-02-06T08:38:03Z

@@ Line 106: / Line 106: @@
 ===Deleting/Invalidation===
 Groups cannot be removed from an admin's inherited group list.  However, admins can be invalidated.  This lets an authentication system, such as SQL, remove individual admins to refresh their privileges.  Resources used by an admin object are always reclaimed efficiently.
 [[Category:SourceMod Development]]
 [[Category:SourceMod Scripting]]

@@ Line 19: / Line 19: @@
 *<tt>bool[]</tt>: Represents a bit array, where each index <tt>i</tt> of the array specifies whether AdminFlag <tt>i</tt> is enabled (true) or disabled (false).
 *<tt>FlagBits</tt>: Represents an unsigned 32bit integer, where each bit <tt>n</tt> of the integer specifies whether AdminFlag <tt>n</tt> is enabled (bit 1) or disabled (bit 0).  Convenience macros are available for dealing with bitwise numbers.  They are found in <tt>IAdminSystem.h</tt> and each start with <tt>ADMFLAG</tt> instead of <tt>Admin</tt>.
 ==Overrides==

@@ Line 19: / Line 19: @@
 *<tt>bool[]</tt>: Represents a bit array, where each index <tt>i</tt> of the array specifies whether AdminFlag <tt>i</tt> is enabled (true) or disabled (false).
 *<tt>FlagBits</tt>: Represents an unsigned 32bit integer, where each bit <tt>n</tt> of the integer specifies whether AdminFlag <tt>n</tt> is enabled (bit 1) or disabled (bit 0).  Convenience macros are available for dealing with bitwise numbers.  They are found in <tt>IAdminSystem.h</tt> and each start with <tt>ADMFLAG</tt> instead of <tt>Admin</tt>.
 ==Overrides==

← Older revision		Revision as of 19:20, 19 January 2008
Line 38:		Line 38:
	</ol>		</ol>

		+	The primary function for computing immunity is <tt>CanUserTarget()</tt> (clients.inc).

	=Cache Types=		=Cache Types=

← Older revision		Revision as of 00:17, 16 November 2007
Line 107:		Line 107:

	[[Category:SourceMod Development]]		[[Category:SourceMod Development]]
		+	[[Category:SourceMod Scripting]]

@@ Line 59: / Line 59: @@
 ==Global Override Cache==
-The global override cache stores information about global overrides.  Every operation to this cache occurs both retroactively and for future command creations.
+The global override cache stores information about global overrides.  Every operation to this cache occurs both retroactively and for future command creations.  An override need not be tied to a command; however, if a command has the same name, the command will inherit that override's permissions.
 ===Writing/Appending===
 New entries to the global override cache will affect both already existing commands and future commands registered during the cache's lifetime.
-Each command can be assigned one access flag.  Currently, it is not possible to specify more than one flag permission on a command.  Commands which wish to do this must have manual access checking.
+Each command can be assigned any or no access flags.
 ===Deleting/Invalidation===
-Deleting a part or the whole of the global override cache will cause affected commands to revert to their original access behaviour.
+Deleting a part or the whole of the global override cache will cause affected commands to revert to their original access behavior.
 ==Group Cache==

@@ Line 26: / Line 26: @@
 ==Immunity==
-Lastly, there are "immunities."  These refer to the ability of one admin to "target," or perform a generic action on another admin.  There is a specific set of heuristics for determining whether a targeting user is able to affect a targetted user:
+Immunity in SourceMod is based on ''immunity levels'', which are arbitrary numbers greater than or equal to zero.  If an admin has an immunity level of 0, that admin has no immunity.  An admin can only target other admins if their immunity level is greater than or equal to the target's immunity level.  This functionality can be tweaked via <tt>sm_immunity_mode</tt> in <tt>cfg/sourcemod.cfg</tt>.
 <ol>
-  <li>If the targeting AdminId is INVALID_ADMIN_ID (not an admin), targeting fails.</li>
+  <li>If the targeting AdminId is <tt>INVALID_ADMIN_ID</tt> (not an admin), targeting fails.</li>
-  <li>If the targetted AdminId is INVALID_ADMIN_ID (not an admin), targeting succeeds.</li>
+  <li>If the targeted AdminId is <tt>INVALID_ADMIN_ID</tt> (not an admin), targeting succeeds.</li>
-  <li>If the targeting admin is root, targeting suceeds.</li>
+  <li>If the targeted AdminId is the same as the targeting AdminId (i.e. self-targeting), then targeting succeeds.</li>
-  <li>If the targetted admin has global immunity, targeting fails.</li>
+  <li>If the targeting admin is root, targeting succeeds.</li>
-  <li>If the targetted admin has default immunity, and the targeting admin belongs to no groups, targeting fails.</li>
+  <li>If the targeted admin has access higher than the targeting admin (determined by the <tt>sm_immunity_mode</tt> rules), then targeting fails.</li>
-  <li>If the targetted admin has specific immunity from the targeting admin via group immunities, targeting fails.</li>
+  <li>If the targeted admin has specific immunity from the targeting admin via group immunities, targeting fails.</li>
-  <li>Targeting succeeds if it has run through the above tests with no result.</li>
+  <li>Targeting succeeds.</li>
 </ol>
@@ Line 74: / Line 75: @@
 *'''Add Flags''': These are flags added to any user who inherits the group.
 *'''Immunity''': Specifies rules for which admins cannot target this group.
-**'''Default''': Immunity from any user without a group.
+*'''Immunity Level''': If a user inheriting the group has a lower immunity level than this number, they inherit the new higher value from the group.
-**'''Global''': Immunity from any non-root user.
+*'''Specific''': Immunity from a list of specific groups.
 *'''Overrides''': Allows commands or command groups to be allowed or denied to this group.

← Older revision		Revision as of 21:38, 6 February 2007
Line 106:		Line 106:
	Groups cannot be removed from an admin's inherited group list. However, admins can be invalidated. This lets an authentication system, such as SQL, remove individual admins to refresh their privileges. Resources used by an admin object are always reclaimed efficiently.		Groups cannot be removed from an admin's inherited group list. However, admins can be invalidated. This lets an authentication system, such as SQL, remove individual admins to refresh their privileges. Resources used by an admin object are always reclaimed efficiently.

−	[Category:SourceMod Development]	+	[[Category:SourceMod Development]]

@@ Line 11: / Line 11: @@
 =Permissions=
 Permissions are granted through the ''AdminFlag'' data type.  Each flag specifies an action or permission type that requires administrative access.  For each admin, the set of flags which are enabled is called the admin's ''effective permissions''.
@@ Line 19: / Line 20: @@
 *<tt>FlagBits</tt>: Represents an unsigned 32bit integer, where each bit <tt>n</tt> of the integer specifies whether AdminFlag <tt>n</tt> is enabled (bit 1) or disabled (bit 0).  Convenience macros are available for dealing with bitwise numbers.  They are found in <tt>IAdminSystem.h</tt> and each start with <tt>ADMFLAG</tt> instead of <tt>Admin</tt>.
 Permissions can also be granted through ''overrides''.  Overrides are specific permissions that override the default effective permissions.  They can act on both commands and command groups (a command group is a set of commands under a common name).  There are two types of overrides:
 *'''Global Overrides''': These override the default admin flag(s) required for a given command or command group.
 *'''Group Overrides''': These override whether members of the group can or cannot access a given command.

@@ Line 9: / Line 9: @@
 Note the difference between the two: In the first example, the cache is being used as a lookup mechanism itself, as well as storing the permissions.  In the second example, the cache is being used ''only'' to store permissions, since lookup was done by the SQL server.
 =Permissions=
 Permissions are granted through the ''AdminFlag'' data type.  Each flag specifies an action or permission type that requires administrative access.  For each admin, the set of flags which are enabled is called the admin's ''effective permissions''.
 Permissions can also be granted through ''overrides''.  Overrides are specific permissions that override the default effective permissions.  They can act on both commands and command groups (a command group is a set of commands under a common name).  There are two types of overrides:
@@ Line 69: / Line 74: @@
 ==Admin/User Cache==
-The user part of the cache stores all information about currently known admins.  Admins stored this way can either be ''live'' (as in, their permissions are currently in use by a player), or ''idle'' (cached for future lookup).
+The user cache stores all information about currently known admins.  Users stored can either be ''live'' (as in, their permissions are currently in use by a player), or ''idle'' (cached for future lookup).
 Users have the following properties: