[Resolved] ULX Group Ordering Question (By inheritance?)

[allofmywutsteam]

ULib v..2.6 // ULX v..3.70 // Game mode: TTT

I'm curious how the ULX groups are ordered in the xgui. I see some groups are ordered according to inheritance, but some groups are sitting above even the highest group.

My hierarchy goes:
owner > superadmin > admin > respected (and respected ID's) > members (and respected ID's > user

Problem:


Sample inheritance:

[Megiddo]

It is, as you guessed, based on inheritance. XGUI gets the data from this function and then flattens it. The only guarantee is that a group will never be below what it's inheriting from.

[allofmywutsteam]

But in my image, the top Steam ID is sitting WAY above a group it inherits from (respected). And this is the case for several other groups too, that are randomly listed

[Megiddo]

Yes, a group will always be above what it inherits from.

[allofmywutsteam]

Yes, a group will always be above what it inherits from.

if thats the case, then why is owner underneath it... that steam ID at the top doesn't inherit from owner.

[Megiddo]

A group will always be above what it inherits from, but there is no information conveyed other than that. E.G., everything that inherits from "user" will always be above user, but that doesn't mean that "user" can't be above other groups (as long as they don't inherit from "user").

[Megiddo]

I realize it may be confusing, but there's no great way to display tree-based information in a flat list. Nor was this list really intended to be used to determine that information.

[allofmywutsteam]

I realize it may be confusing, but there's no great way to display tree-based information in a flat list. Nor was this list really intended to be used to determine that information.

Understandable. I'll close this out. Thank you!

[Bite That Apple]

The real question is why do you have groups with steam ids.

[allofmywutsteam]

The real question is why do you have groups with steam ids.

That's a good question. I had originally used unique names for groups, but as time passed on, there were users who hadn't joined the server in some time, and there were users who changed their names. So it was hard to track which ulx group was associated with which user. Especially when I'm in my addons giving permissions to models, weapons, etc. So for me, tracking a user down in game and in addons is easier by ID than it is by name. For me it's a cleaner naming convention.

[roastchicken]

I think Apple's question extends to "Why do you have groups for single users?"

[allofmywutsteam]

I think Apple's question extends to "Why do you have groups for single users?"

As a perk, members can win/earn custom ranks to give themselves some flair at certain times. They were once able to buy them, but given I recently brought back the server, and I had wiped out the 70+ previous groups, I was giving some out.

[roastchicken]

What's the point in creating a whole group for it though? Why not just 'ulx adduser'? Seems like bad practice to me.

[JamminR]

Don't get us wrong - we're not saying you're going to server admin <-censor-bad place-censor-> for using ULX^* the way you want.
_{(* really, this wouldn't even have to be ULX, it could be straight gmod group control through /settings/users.txt)}
It's just not efficient management.
Grouping is meant to allow a..wait for it... group of users to have different access than some other group.
As roastchicken alludes to, efficiency would dictate, if giving access perks higher than one group, but below another, you give that middle group the standard perks and add the user to it.
If you wanted to give command perks to those in that group different than the others in that same group, but didn't have enough members to make a whole new group above that one, then you simply use userallow to give that user access to whatever command. Or, if you decided after 2 or 3 people starts getting that access, and thought the rest of the group deserved the access too, then groupallow.

ULX is meant to make what can be a challenging job easier.
It seems your current group decisions still remain complicated.

[allofmywutsteam]

Don't get us wrong - we're not saying you're going to server admin <-censor-bad place-censor-> for using ULX^* the way you want.
_{(* really, this wouldn't even have to be ULX, it could be straight gmod group control through /settings/users.txt)}
It's just not efficient management.
Grouping is meant to allow a..wait for it... group of users to have different access than some other group.
As roastchicken alludes to, efficiency would dictate, if giving access perks higher than one group, but below another, you give that middle group the standard perks and add the user to it.
If you wanted to give command perks to those in that group different than the others in that same group, but didn't have enough members to make a whole new group above that one, then you simply use userallow to give that user access to whatever command. Or, if you decided after 2 or 3 people starts getting that access, and thought the rest of the group deserved the access too, then groupallow.

ULX is meant to make what can be a challenging job easier.
It seems your current group decisions still remain complicated.

Ohhhhhhhhhhhhhhh you just blew my mind. I've used userallow before but never too much. But you're right. Only reason I was using groups was because I could assign a user unique configurations for specific packages they donate for. But right now, I'm literally just making groups for custom name/color configs, which can be done by ID anyway, and not by group.

You just made my life so much easier lol

The addons I was concerned about were:
-- pointshop-master
-- TTT-EasyScoreboard-master
-- TTTDamagelogs-master
-- WeaponSelectionMenu

Pointshop isn't affected because members still get the same access. EasySB isn't affected because I can still apply unique stuff by ID. DMG logs isn't affected because everyone can access logs anyway. Weapon selection isn't affected because members can access certain weps anyway.

The only time I could see myself crating a unique group would be for donors who want access to certain weps, but not models. And vice versa. But even then, that would decrease the amount of editing by a lot lol Not that I had to do much, but it's always a hassle having to go into different files every time.

The only issue I can think of for user allow is IF I were to hand out some extra fun commands (^ only), then how would i know down the line who has access to said command? Or would I just need to personally track them? I guess I could use ulx warn, but that's pointless. Suggestions for this situation?