Multiple Usergroups?

[stapler2025]

Is it possible at all to add a single user to multiple usergroups?  I was admin on a server a couple years ago, and remember them having this functionality (where you'd set an initial usergroup, and then grant someone access to a secondary usergroup).

[JamminR]

No, but, yes.
ULib's inheritance tree allows "Player:IsUserGroup(Z)" to return true for any group that inherits it.
So, if you have Groups X, Y, Z, and X inherits Y inherits Z, Player is assigned group X, IsUserGroup(Z) would return true.

[stapler2025]

Can't you do like "ulx userallow user donator" and add them to inherit another group?  Or will I need to setup a bunch of usergroups like "superadmin and donator" and "admin and donator" and "trusted and donator"?

[stapler2025]

Or, how could we set it up so that we're looking at giving people permission to things based on their "allow" settings?

We're running a darkrp server (surprise surprise, right?) and naturally want to have VIP jobs and such.  The old code we're going off of, has it configured in the jobs so that if they have ALLOW_DONATOR and some other jazz, it would let them utilize that job, etc.

I know on the darkrp wiki, it has us add "       customCheck = function(ply) return ply:GetUserGroup() == "donator" end," to the job code, and that checks for the group, but is there a way to check for user allow?

Edit:  ACCESS_ALL--[[ACCESS_DONATOR]] -- that's the code they were using in their job, then whenever they granted someone access to donator, it gave the person access to donator tagged things.

[JamminR]

userallow has no inheritance control. only addgroup does.
Ulib will always follow the group inheritance for the group the user is in unless can_target is set differently.
You add users to a single group that may or may not inherit other groups.
I've no idea how DarkRP controls access.
If it's group based control, then ULX group inheritance can be used.
The code example you show, GetUserGroup, is strictly a ULib function.
GetUserGroup will return the only group they are officially adduser'ed to (a single group)
IsUserGroup would probably be better for general checks.
IsUserGroup(donator) would return true if any group they were a part of inherited donator, or if they were in the donator group.

[stapler2025]

What I'm trying to avoid here, is making multiple usergroups for absolutely no reason.  Don't see the need to have two of every usergroup, for one of them to be setup with inheritance to a donator group.

Is there a way/query I could use to see if a user has the "donator" flag, under allow?  for example: ulx userallow dave donator - adds the donator flag to their user.  Can I pull that and see if it's valid, then display the job?

Clearly it's possible, because an old server did it, I'm just not sure how.

[Megiddo]

We used to support multiple inheritance but removed that a while back. But yes, you could add a donator flag to the appropriate users using userallow and checking for it using ULib.ucl.query.

[stapler2025]

At work right now, so can't do anything server-wise, but would it go something like this?

customCheck = function(ply) return ply:query( "donator" ) end

[JamminR]

At work right now, so can't do anything server-wise, but would it go something like this?

customCheck = function(ply) return ply:query( "donator" ) end

Yep.

[stapler2025]

Yep.

Doesn't seem to be working unfortunately, it still lets me become that job even if I'm denied access to donator flag.

[MrPresident]

This method wouldn't allow for you to assign entire groups worth of access in the way you are wanting.

For instance doing ply:query("donator") wouldn't give a player with that access string access to everything someone with the group donator has.


The way Megiddo suggested you do it would be a bit trickier. You would have to modify all of your donator content to use ply:query("donator") instead of IsUserGroup("donator") and then give the users you want access access to the "donator" access string using ulx userallow <player> "donator"

Does that make sense?

[stapler2025]

This method wouldn't allow for you to assign entire groups worth of access in the way you are wanting.

For instance doing ply:query("donator") wouldn't give a player with that access string access to everything someone with the group donator has.


The way Megiddo suggested you do it would be a bit trickier. You would have to modify all of your donator content to use ply:query("donator") instead of IsUserGroup("donator") and then give the users you want access access to the "donator" access string using ulx userallow <player> "donator"

Does that make sense?

Sorta.  Right now I'm just testing it out on a single donator job to see if I can get things to work.

Code: [Select]

TEAM_WEAPON = AddExtraTeam("Weapon Distributor", {
color = Color(200, 130, 30, 255),
model = "models/player/Hostage/Hostage_02.mdl",
description = [[Sell guns for 25% cheaper than other vendors, set up a shop and gain lots of cash.]],
weapons = {},
command = "weapondistributor",
max = 3,
salary = 45,
vote = false,
hasLicense = true,
mayorCanSetSalary = false,
customCheck = function(ply) return ply:query("donator") end,
customCheckFailMsg = "You need to be a donator to become this job."
})
That's what I have now, and it's letting anybody become that job, is there something else I should be doing with that?

[Megiddo]

Try returning false from the custom check function just to make sure it's working.

[stapler2025]

Changed it to function(ply) return false end, - and it didn't show the job anymore which would be intended I assume?

[Megiddo]

Perhaps you accidentally gave the "user" group permission to "donator"? Try various debugging techniques to see what's going on here -- printing the result of the query in that inline function, testing it directly on players, etc.