Groups vs. Teams - Why having an owner group is useless and stupid

[MrPresident]

This thread is here because:

Even though you set up your ULX groups correctly and they are working the way you want them to, if you ever installed a different 3rd party addon that had admin privileges, it MAY give you superadmin access because ULX overwrites how IsSuperAdmin works to include derivative groups, however your superadmins would also have top level access. You would not be able to change this even if you wanted to without editing the lua files of the addon you installed.

My point I was trying to make is that GarrysMod (Not ULX) handles superadmin as THE root group. If you want to be an 'owner' the best way to do that is to relabel superadmin as 'Owner' with UTeam or whatever else handles teams for your gamemode.

If you've had no issues with the way you have yours set up, you should be thankful. You are either very lucky, or have more working knowledge of ULX/LUA than most of the users that come here.

[Dartouious]

Could i rename the superadmin group and it still have a;; the same permissions and i wouldnt have to change anything in side the server. or would that screw everything. Becasue i would like my owner calss to be called Dictator. With all the permissions

[JamminR]

Simply put, It would break everything.
Gmod expects and programs for three groups - superadmin, admin, and user.
All other groups are custom, and no 3rd party script is guaranteed to have any idea what they are if not one of those three.

[MrPresident]

Basically Dartouious, the point I am trying to make is that in gmod a group is not a team.

You could CALL your superadmin group Dictator using something like UTeam and it would appear as that in the scoreboard while remaining superadmin in the code. As long as you don't rename the GROUP you should be fine.

The problem is when server owners want to have a group higher than superadmin, and then they complain when some things don't work properly.

[JamminR]

And UTeam isn't made for other gamemodes than Sandbox because, well, they have thier own teams which UTeam would break.
Simply put, renaming superadmin or admin group breaks stuff

[syn.]

And UTeam isn't made for other gamemodes than Sandbox because, well, they have thier own teams which UTeam would break.
Simply put, renaming superadmin or admin group breaks stuff

started server, didn't know anything, broke stuff with 3rd party stuff on TTT, deleted everything, started server again, broke even more stuff. story of my server lol:)

[Avoid]

Hey there,
I really do have to agree with Mr.President, people should just stop screwing around with ULX groups, because there really is no point in having a group higher than superadmin which is equivalent to root in Linux systems.
Sometimes people join my server and ask who the owner is, as I am "just" a superadmin. 

Just my two cents,
Avoid

[JamminR]

Avoid, just to make sure you're clear, this has nothing to do with just 'ULX' groups.
GMOD expects superadmin to be root.
ULX allows for custom groups, but, no other addon may know what those groups are, and, people keep coming here acting like ULX is broken.

[Bryantdl7]

I was careful with my inheritance for ranks, and I made an owner rank that is above superadmin. I have no issues with ULX.

[Livaco]

started server, didn't know anything, broke stuff with 3rd party stuff on TTT, deleted everything, started server again, broke even more stuff. story of my server lol:)

lol if u need a expert just hire one instead of breaking your serever

[Aharon Tager]

Honestly, the way I do it on my server is to have a ranks ladder (user < member < regular < veteran < vip < vip+ < mod < head mod < admin < head admin) with all of those inheriting from the one under them and the default groups (operator = mod, admin = admin) sitting in their place. Then there are 2 groups, manager (myself) and owner (the 2 owners) who inherit from superadmin which can therefore remain untouched and still work fine for the code. i have yet to run into any issues with this configuration and if any of the ULX team members see a potential issue, please post and tell me what it is. This was the simplest way I could think of to have multiple groups with superadmin access yet different teams for displaying on the scoreboard and such.

[Caustic Soda-Senpai]

Honestly, the way I do it on my server is to have a ranks ladder (user < member < regular < veteran < vip < vip+ < mod < head mod < admin < head admin) with all of those inheriting from the one under them and the default groups (operator = mod, admin = admin) sitting in their place. Then there are 2 groups, manager (myself) and owner (the 2 owners) who inherit from superadmin which can therefore remain untouched and still work fine for the code. i have yet to run into any issues with this configuration and if any of the ULX team members see a potential issue, please post and tell me what it is. This was the simplest way I could think of to have multiple groups with superadmin access yet different teams for displaying on the scoreboard and such.

You seem to misunderstand.

GMOD expects superadmin to be root.

Which means GMOD ITSELF expects superadmin to be the highest group. Meaning that, given the proper circumstances, a player with superadmin access will have power over someone with "owner" status. Simply because that's how Garry made it.

[MrPresident]

Honestly, the way I do it on my server is to have a ranks ladder (user < member < regular < veteran < vip < vip+ < mod < head mod < admin < head admin) with all of those inheriting from the one under them and the default groups (operator = mod, admin = admin) sitting in their place. Then there are 2 groups, manager (myself) and owner (the 2 owners) who inherit from superadmin which can therefore remain untouched and still work fine for the code. i have yet to run into any issues with this configuration and if any of the ULX team members see a potential issue, please post and tell me what it is. This was the simplest way I could think of to have multiple groups with superadmin access yet different teams for displaying on the scoreboard and such.

This may work in ULX, but only because we override some functions to trick gmod into thinking that those groups are superadmin.
All I was trying to say in the main post is that superadmin should always be the highest group. You can have it called owner, and you can have other groups inherit it, but it should always be the highest.

People run into targeting and permission issues all the time where groups 'above' superadmin don't behave properly.

[JamminR]

all the time where groups 'above' superadmin don't behave properly.

Clarification
They are likely behaving exactly 100% the way Garry (and perhaps Valve/Source?) intended.
Just not behaving how some players might expect when they read some instruction that tells them to set an 'owner' or other group expecting it to be higher.
superadmin > admin > user
Anything else is just icing on the cake, and the cake is often known to Gmod as a lie.

[Ryan Hemmet]

On any server I have made or developed on I have followed this 
On some servers I hop on, I inform them about this thread and give them a brief summary of why they should not have ranks above superadmin. I have got the owner of a few of them to change the ranks around.