Exactly how does the user list and allows/denies work?

[Megiddo]

General User Management Concepts:
User access is driven by ULib's Ulysses Control List (UCL). This list contains users and groups, both have allow and deny lists. The allow and deny lists contain access strings like "ulx slap" or "ulx phygunplayer" to show what a user and/or group does and does not have access to. If a user has "ulx slap" in their user allow list or in the allow list of one of the groups they belong to, they have access to slap. If a user has "ulx slap" in their user DENY list or in the deny list of one of the groups they belong to, they are DENIED the command, even if they have the command in one of their allow lists. In this way, deny takes precedence over allow.

You cannot modify the superadmin group or any superadmin users from a client that isn't the listen server host. This is a built in safety feature to ensure that their are no attempts at takeovers. You can, however, modify the group and users from a listen server host or a dedicated console.

ULib supports admin immunity. This makes it so lower admins cannot target users with immunity. (IE, peons can't kick the superadmin) However, some admins can overcome immunity (by default, all superadmins can do this). In this way, superadmin can still kick peons with immunity.


More Advanced Concepts:
"immunity" is the access string used for immunity, "overcomeimmunity" is the access string used for overcoming immunity. By default, superadmins have access to overcomeimmunity".

Groups have inheritance. You can specify what group they inherit from in the addgroup command. If a user is in a group that has inheritance, UCL will check all groups connected in the inheritance chain. But, please note that it only checks for ALLOWS in the inherited groups and ignores DENIES.

If you want to add a user to more than one group or add more than one group into another group's inheritance, you'll need to modify the garrysmod/data/ULib/groups.txt and/or data/ULib/users.txt file(s) by hand; these commands do not support doing that.


User Management Commands:

ulx adduser <user> <group> [<immunity>] - Add the specified CONNECTED player to the specified group with or without immunity. This command will give the user PERMANENT access, so please be careful!
The group MUST exist for this command to succeed. Use operator, admin, superadmin, or see ulx addgroup. You can only specify one group. See above for explanation on immunity.
Ex 1. ulx adduser "Someguy" superadmin 1  -- This will add the user "Someguy" to the group superadmin with immunity
Ex 2. ulx adduser "Dood" monkey           -- This will add the user "Dood" to the group monkey without immunity, on the condition that the group exists

ulx removeuser <user> - Remove the specified CONNECTED player from the permanent access list.
Ex 1. ulx removeuser "Foo bar"            -- This removes the user "Foo bar" forever

ulx userallow <user> <access> [<revoke>] - Puts (or removes) the access on the USER'S ALLOW list. If revoke is "1", it removes.
See above for explanation of allow list vs. deny list, as well as how access strings work.
Ex 1. ulx userallow "Pi" "ulx slap"       -- This grants the user "Pi" access to "ulx slap"
Ex 1. ulx userallow "Pi" "ulx slap" 1     -- This revokes user "Pi"'s access to "ulx slap"

ulx userdeny <user> <access> [<revoke>] - Puts (or removes) the access on the USER'S DENY list. If revoke is "1", it removes.
See above for explanation of allow list vs. deny list, as well as how access strings work.
Ex 1. ulx userdeny "Bob" "ulx slap"       -- This restricts the user "Pi" access to "ulx slap"
Ex 1. ulx userdeny "Bob" "ulx slap" 1     -- This revokes the user "Pi"'s restriction to "ulx slap" (but they won't necessarily have access to it)

ulx addgroup <group> [<inherit_from>] - Creates a group, optionally inheriting from the specified group. See above for explanation on inheritance.

ulx removegroup <group> - Removes a group PERMANENTLY. Also removes the group from all connected users and all users who connect in the future. If a user has no group besides this, they will become guests. Please be VERY careful with this command!

ulx groupallow <group> <access> [<revoke>] - Puts (or removes) the access on the GROUP'S ALLOW list. If revoke is "1", it removes. See above for explanation of allow list vs. deny list, as well as how access strings work.

ulx groupdeny <group> <access> [<revoke>] - Puts (or removes) the access on the GROUP'S DENY list. If revoke is "1", it removes. See above for explanation of allow list vs. deny list, as well as how access strings work.


Questions?
If there's something we can clarify, please let us know.

[MrPresident]

Also, if you are a developer, you can use the allow/deny lists in your scripts.

Here is how you would call this in your scripting.

Code: [Select]

Ply:query("accessflag")

of course, ply in this example is simply a user entity, this would need to be defined in your function before being called in your query check.

accessflag is whatever you wish for it to be, you would then give access to that flag to users in game with ulx userallow or through the groups.txt file in your Data/ULib folder.

In this example I have a flag set up to return false when a user without the appropriate flag tries to spawn an entity that I have reserved for people with this flag.

Code: [Select]

if !Ply:query("fairy") then
ULib.tsay( Ply, "This SENT is restricted to Administrators and Donators.", true )
return
end


[RalphORama]

Is there a place I could go for more in-depth instructions for setting up the groups.txt file?
This makes sense but I already have stuff set up and I'd just like to double-check that I have it right.

Thanks!

[Megiddo]

Is there a place I could go for more in-depth instructions for setting up the groups.txt file?
This makes sense but I already have stuff set up and I'd just like to double-check that I have it right.

Thanks!

We don't recommend directly modifying that file. You should be using the in-game commands instead.

[JamminR]

+1(00000) to what Megiddo said.
But if you're an uber-geek who promises not to come here and waste the precious little time we have to troubleshoot why your groups stopped working after editing them, you can where those files are stored in several of the other FAQs (regarding troubleshooting access and uinstalling Ulib)

[Sgt.Blue]

I'm a bit confused as to how immunity and overcomeimmunity works.

[JamminR]

Immunity and Overcomeimmunity are no longer used. This FAQ was just never updated.
Can_Target is now used in it's place, and is much more versatile.
See How exactly does can_target work?, the topic it points to, and the many questions within the forum we've answered regarding it and inheritance.