We've wanted this for years. There are too many conflicts between the admin mods and the solutions implemented by individual admin mods are not sufficient.
I've made a pre-alpha draft super WIP document:
[url]https://docs.google.com/document/d/1QIRVcAgZfAYf1aBl_dNV_ewR6P25wze2KmUVzlbFgMI/edit?usp=sharing[/url]
I want to invite anyone capable to criticise this document and think about the consequences it will have on admin mods.
Specifically, I want to invite these people behind these addons:
- ULX (megiddo?)
- Serverguard (Alex Grist)
- Evolve (whoever maintains it)
- Exsto (is Prefan still alive?)
- Assmod (is this still a thing?)
- <private/WIP admin mod>
I want [B]you[/B] guys to specifically think about:
- Whether it is possible to implement CAMI in your admin mod, and walls you might face
- What problems CAMI does not solve yet and should be addressed
The people mentioned above can get write access to the GDocs document. I need your opinion, for I need your acceptance.
This thread is for discussion.
[B]NOTE: [/B] CAMI is a WIP. I started it just today, I want to involve you from the beginning.
[B]Nothing[/B] is set in stone yet. [B]Do not[/B] implement this yet. For all I know this might be fully recoded.
[QUOTE=FPtje;47256089]-snip-[/QUOTE]
I severely dislike your concept of "immunity". I would love to see something like [url=http://wiki.bukkit.org/Understanding_Permissions]craftbukkit[/url] did; for example [url=https://github.com/mcMMO-Dev/mcMMO/blob/fe29bb4b9fcdbb90c4a042bd0a8ade0565371ffb/src/main/java/com/gmail/nossr50/util/commands/CommandRegistrationManager.java#L70-L75]McMMO[/url]
The number does limit functionality, but it is what I've seen in most admin mods. Whatever the immunity part will be, it must be possible to translate back and forth between the admin mod's implementation and the CAMI's implementation.
[QUOTE=FPtje;47256169]The number does limit functionality, but it is what I've seen in most admin mods. Whatever the immunity part will be, it must be possible to translate back and forth between the admin mod's implementation and the CAMI's implementation.[/QUOTE]
You could probably get away with something like.. idk maybe
[lua]
local opposites ={
kick = "kick_immune";
}
hook.Add("CAMI.CanTarget", "ADMINGEMOD", function(p, other, permission) -- a hook, to allow even more flexibility
-- defaults to false
if(not p:HasPermission(p) or other:HasPermission(opposites[permission])) then return nil; end
return p:AdmingeMod_CanTarget(other) or nil;
end);
FindMetaTable[[Player]].AdmingeMod_CanKick = function(self,other)
return hook.Run("CAMI.CanTarget", self, other, "kick") or false;
end
function adminge.kick(target, caller, why)
if(caller:AdmingeMod_CanKick(target)) then
target:Kick(why);
end
end)
[/lua]
[QUOTE=FPtje;47256089][B]Privileges[/B]
A privilege is a witness of permission to perform a (group) of actions. Privileges are intrinsically linked to usergroups in a many-to-many relationship. Privileges cannot be assigned to players directly, for that would lead to conflicts between the privileges of a player and of their usergroup. Privileges can vary from being allowed to read certain logs to being allowed to kick a player. The name of the privilege is to be indicative of what it represents.
[/QUOTE]
I disagree with the lack of priviliges being assignable to players directly. I think group permissions should be applied first from lowest 'power level' to higest so that a player can be in multiple usergroups which I'd like to see working similar to linux groups. A 'group' is given access to a specific set of tools, like a playx group that can have three priviliges: play, stop, or 'spawn a playx player' for example. Then after all group priviliges are applied apply the users direct priviliges to overwrite any previous group priviliges (or negate/grant powers like in the ts doc below).
Another system that I tend to like is the [url=http://www.teamspeak.com/media_repository/documents/TeamSpeak%203%20Permissions%20Guide_01.pdf]Teamspeak 3 permissions system[/url]. Having a needed_power privilige alongside some priviliges is more 'dynamic' than a user wide immunity that gets checks. Also having skip/grant/negate members for each privilige like teamspeak does makes the system more 'fullproof' I think.
All of this is overkill for most admin mods but if you're designing a standard I'd think its best to have the system it's designing be as 'dynamic' as possible.
I worked on Evolve 2014 when I was starting out lua, and I really like this idea. I think a unified standard would have many advantages, including easier backups if you coded with a MySQL backend and compatibility with ranks and users inside them. In regards to immunity as a number:
Pros:
-Maintains backwards compatibility with existing admin mods
-Easier to set up as a novice end user.
-Potentially easier to program for.
Cons:
-Less versatility. Maybe mods should be able to hand out certain punishments to guests only, but not target respected for that command (e.g. ULX Gimp is really mean, and if a player is respected, maybe they should be spared.) You couldn't do this with immunity as just a number.
-It makes you more likely to be deprecated sooner, if you stick with old and worse features for compatibility.
I think maybe a hybrid system would be best, allowing command immunity overrides but still maintaining a number for those who just want to get it done.
[QUOTE=mcd1992;47256251]I disagree with the lack of priviliges being assignable to players directly. I think group permissions should be applied first from lowest 'power level' to higest so that a player can be in multiple usergroups which I'd like to see working similar to linux groups. A 'group' is given access to a specific set of tools, like a playx group that can have three priviliges: play, stop, or 'spawn a playx player' for example. Then after all group priviliges are applied apply the users direct priviliges to overwrite any previous group priviliges (or negate/grant powers like in the ts doc below).
Another system that I tend to like is the [url=http://www.teamspeak.com/media_repository/documents/TeamSpeak%203%20Permissions%20Guide_01.pdf]Teamspeak 3 permissions system[/url]. Having a needed_power privilige alongside some priviliges is more 'dynamic' than a user wide immunity that gets checks. Also having skip/grant/negate members for each privilige like teamspeak does makes the system more 'fullproof' I think.
All of this is overkill for most admin mods but if you're designing a standard I'd think its best to have the system it's designing be as 'dynamic' as possible.[/QUOTE]
GreyGeist words it nicely. Your suggestion is good in essence, but it's very complicated, and one that is not really implemented by any admin mod. The interface MUST unify admin mods. Admin mods that use a number immunity system (like FAdmin) MUST be able to implement CAMI. Otherwise the whole interface has no use.
I like Grey's idea of a hybrid system, one that is compatible with current admin mods and allows more advanced permission structures.
I feel as though people shouldn't be using more than one admin modification/permission at a time - it would obviously cause conflicts. Gamemodes that need some sort of access/permission control can use IsAdmin, IsSuperAdmin, and IsUserGroup; it should be up to the gamemode to handle custom user groups that the server specifies.
[QUOTE=`impulse;47256625]I feel as though people shouldn't be using more than one admin modification/permission at a time - it would obviously cause conflicts. Gamemodes that need some sort of access/permission control can use IsAdmin, IsSuperAdmin, and IsUserGroup; it should be up to the gamemode to handle custom user groups that the server specifies.[/QUOTE]
Admin mods should all be returning their user group with GetUserGroup too as a lowercase string, so any gamemodes that require user group cherry picking such as "donator" can just use IsUserGroup or GetUserGroup.
[QUOTE=`impulse;47256625]I feel as though people shouldn't be using more than one admin modification/permission at a time - it would obviously cause conflicts. Gamemodes that need some sort of access/permission control can use IsAdmin, IsSuperAdmin, and IsUserGroup; it should be up to the gamemode to handle custom user groups that the server specifies.[/QUOTE]
Much like CPPI, CAMI will do two things: unify admin mods and provide a common interface for third parties to use. DarkRP has privileges to manage doors, run rp_jobname commands and see logs. It currently registers them with FAdmin and falls back on IsAdmin when FAdmin is disabled. IsAdmin and IsUsergroup is not good enough because I want customisability. I also don't want FAdmin to be the only admin mod the can handle DarkRP privileges. CAMI is the solution.
I am not much of a DarkRP player or server owner (anymore), but the changes you made since 2.4.2 are incredible. I took a look at your code a while back, and : my respects. You made the code so much cleaner and easier to use and that although DarkRP players/owners consist (mostly) of unappreciative shit, [U]you kept going[/U].
Back on topic: I totally agree with the idea of adding support for other admin addons. But you should think about simplifying the whole thing:
Why not make some simple Hooks for them?
Like: CanPlayerUseCommand or CanPlayerTargetPlayer (ofc with a different naming)
Alright, thanks a lot for the feedback! I've made some changes:
- Players can have privileges now. Conflicts are resolved in a way that should be universal amongst all admin mods
- The immunity system can be overriden with an optional can_target(priv, actor, target) function, though it should be considered to integrate new systems into CAMI.
[editline]4th March 2015[/editline]
[QUOTE=freakyy;47256975]I am not much of a DarkRP player or server owner (anymore), but the changes you made since 2.4.2 are incredible. I took a look at your code a while back, and : my respects. You made the code so much cleaner and easier to use and that although DarkRP players/owners consist (mostly) of unappreciative shit, [U]you kept going[/U].
Back on topic: I totally agree with the idea of adding support for other admin addons. But you should think about simplifying the whole thing:
Why not make some simple Hooks for them?
Like: CanPlayerUseCommand or CanPlayerTargetPlayer (ofc with a different naming)[/QUOTE]
There is a can_target in privileges. It might be a good idea to have a generic hook that overrides the privileges' can_target. Thanks for the tip!
I've thought about this a little more and it seems odd that we require some universal interface for something that exists already and comes with GMod. CPPI was needed because Prop Protection didn't exist already in GMod by default and others implemented their own versions of it with little/no similarity so gamemodes had to add compatibility for each one.
This issue is different, the admin mods aren't all making different functions on the player to retrieve their user group or admin status; They're all overriding the same function that already exists in GMod but the gamemodes aren't using them correctly or not using them at all.
CAMI could be an over complication of the problem. People shouldn't have 2 admin mods installed at the same time because they will obviously conflict, but gamemodes should be using the already in place functions for retrieving the players rank. Like I said before, cherry picking ranks can easily be done with GetUserGroup so long as the admin mod always returns the user group in a lowercase string.
[editline]4th March 2015[/editline]
Also, I'm not sure I like the idea of an admin mod interfering with your gamemode functions or vice versa.
I agree with Alex, this isn't needed at all. If anything, you'd be better off improving that abomination called CPPI.
A bigger problem in my opinion is the lack of a common system for adding commands. For almost all my permission checking needs checking the usergroup or just IsAdmin and IsSuperAdmin is enough, but implementing commands for multiple admin systems is a massive pain in ass. I'm pretty sure that most addons advertising themselves as "ULX only" are that because they add commands that work in ULX only.
Maybe it would be better to have a general standard for admin mods written up? Specifying that they should override the player meta functions instead of relying on gamemodes to specifically use the admin mod functions. Hooks such as "PlayerChangedUserGroup" would be useful gamemode or addon creators.
[QUOTE=Alex_grist;47257250]I've thought about this a little more and it seems odd that we require some universal interface for something that exists already and comes with GMod. CPPI was needed because Prop Protection didn't exist already in GMod by default and others implemented their own versions of it with little/no similarity so gamemodes had to add compatibility for each one.
This issue is different, the admin mods aren't all making different functions on the player to retrieve their user group or admin status; They're all overriding the same function that already exists in GMod but the gamemodes aren't using them correctly or not using them at all.
CAMI could be an over complication of the problem. People shouldn't have 2 admin mods installed at the same time because they will obviously conflict, but gamemodes should be using the already in place functions for retrieving the players rank. Like I said before, cherry picking ranks can easily be done with GetUserGroup so long as the admin mod always returns the user group in a lowercase string.
[editline]4th March 2015[/editline]
Also, I'm not sure I like the idea of an admin mod interfering with your gamemode functions or vice versa.[/QUOTE]
The default functions:
- IsAdmin
- IsSuperAdmin
- GetUserGroup
- IsUserGroup
How about:
- Check whether player has privilege
- Create privileges for actions in an addon
- Check whether certain actions can be performed by an admin on a certain player
Currently, the go-to solution is basically this:
[lua]
function hasPrivilege(priv, ass_priv) -- assmod priv is different than usual
if ass then return ass.PlayerHasSomePriv(ass_priv)
elseif serverguard then return serverguards.thing(priv)
elseif ulx then return ulx.thing(priv)
etc.
end
end
end
[/lua]
[url=https://github.com/FPtje/DarkRP/pull/1810]This is the solution [B]YOU [/B]suggested[/url]
This is suboptimal. I refuse to accept it. CAMI can solve this in a MUCH cleaner way.
The usergroup system is not enough. DarkRP was an example, but PlayX was mentioned before. That apparently implemented its own permission system to represent playback and spawning that thing, which is surely to conflict with other admin mods. Besides, many server owners install another admin mod besides FAdmin in DarkRP. They don't disable FAdmin because they also like some features from that. Who are you to tell them they shouldn't do that?
They [B]should[/B] be able to do that, and it is [B]our[/B] responsibility to do our best to make them work together.
That said I of course still want your input on CAMI itself. The way it looks now you can just have one file with most of the functions having a default implementation. Your admin mod would call the functions to create the usergroups and privileges. My admin mod (and other admin mods) can grab the list of usergroups and compare it to their own to see if there are new ones. The explanation is supposed to be very clear and precise, but I suspect the eventual implementation won't be long.
[QUOTE=FPtje;47258683][url=https://github.com/FPtje/DarkRP/pull/1810]This is the solution [B]YOU [/B]suggested[/url][/QUOTE]
Okay, but that was just a temporary fix for FAdmin since it's the only compatibility issue we've encountered because of a gamemode not using the regular IsAdmin or IsSuperadmin functions and neither I or `impulse wanted to go through and create a pull request to add a fallback to FAdmin.
A general permission system seems like it's going to cause more mess than we already have. The current generalisation of the user groups makes sense (at least to me) because it's impractical to rely on specific user groups for your permissions. A super admin has full power, an admin has lesser power. While yes, permissions work to create your own custom ranks and also define what those ranks can use; Why should each gamemode piggyback off of each admin mods permission system?
I'm not sure each gamemode/addon should be adding permissions to my admin mod, since it could cause even more conflicts. This whole solution seems like a good idea, when you think of it as trying to clean up the conflicts caused by having more than one admin mod installed but in reality it feels like a complete over complification. I've always thought it best to keep each addon contained within itself, instead of having a gamemode relying on an admin mods function.
I understand completely why cleaning up the compatibility benefits both server owners and developers. CPPI makes sense because Prop Protection is something that almost every gamemode needs and there was no solution for it built into GMod, that isn't the case here.
[QUOTE=Alex_grist;47258820]Why should each gamemode piggyback off of each admin mods permission system?[/quote]
Because user/admin/superadmin does not provide the customisability that the end user wants. Your permission system does. Making a command admin only is [B]my [/B]decision as a gamemode author. Allowing the custom donatormod to execute that same command is the [B]end user[/B]'s choice. I as gamemode author cannot give them that freedom, [B]you can.[/B]
[QUOTE=Alex_grist;47258820]Why should each gamemode piggyback off of each admin mods permission system?[/quote]
I'm not sure each gamemode/addon should be adding permissions to my admin mod, since it could cause even more conflicts. [/quote]
You don't have to save the privs, in fact I recommend you not to. Just translate the API that you probably already have to CAMI and everyone will be able to enjoy it. All admin mods I've seen have functions for adding privileges and groups. Even assmod did. [U]CAMI integration is just a simple adapter pattern[/U]. Little work, huge benefits.
[QUOTE=Alex_grist;47258820]
CPPI makes sense because Prop Protection is something that almost every gamemode needs and there was no solution for it built into GMod, that isn't the case here.[/QUOTE]
I need it in DarkRP, PlayX needs it too. It [I]IS[/I] the case here.
I don't see how the pull request to add compatibility is any different to what already exists in DarkRP for ULX? Surely this exact code goes against everything you're trying to convince us not to do?
[IMG]http://i.imgur.com/tlAKYDa.png[/IMG]
[QUOTE=FPtje;47258683]-snip-[/QUOTE]
[url=https://github.com/FPtje/DarkRP/commit/870d793b0c56867e1966e926168c79d83ad8935d]This is the fix [b]YOU[/b] created[/url]
It works, it makes sense, it fixes the problem. The problem was that you didn't fall back to the default functions to check whether or not the user has access. You didn't account for custom user groups. I made that initial pull request fully expecting for it to be denied, and having the issue fixed the right way by you; I'm not going to sit there and try to figure out how the hell FAdmin works when you could do it in five minutes, easy peasy.
You say that there's no solution to said problem, but you've done it already. You ask the user to assign said permissions in a user group that's created in FAdmin, and if the player matches the user group, you do whatever needs doing. It's not hard to ask the player what action they want a user group to have access to.
Instead of clogging up admin mods with another interface that they have to follow (which could affect major parts of said admin mods depending on how they're written/structured), you could use the readily available functions. There's also no guarantee that admin mods are going to implement this interface so they can't use it reliably. Which means that they have to add a fallback [i]anyway[/i].
[url=https://github.com/FPtje/DarkRP/issues/894]Here's one of the many compatibility issues between FAdmin and ulx[/url]
[url=https://github.com/FPtje/DarkRP/blob/master/gamemode/modules/fadmin/fadmin/access/sv_init.lua#L104]its solution[/url]
[url=https://github.com/FPtje/DarkRP/issues/963]Someone asking admin mod intercompatibility in 2013[/url]
[url=https://github.com/FPtje/DarkRP/issues/1128#issuecomment-27144929]ULX-specific solutions to questions[/url]
[url=http://forums.ulyssesmod.net/index.php/topic,5142.msg22426.html#msg22426]The incompatibility you've seen between ServerGuard and DarkRP? ULX and FAdmin have had the exact same fight[/url]
These problems can be solved with CAMI. We need this.
[editline]4th March 2015[/editline]
[QUOTE=Alex_grist;47258918]I don't see how the pull request to add compatibility is any different to what already exists in DarkRP for ULX? Surely this exact code goes against everything you're trying to convince us not to do?
[IMG]http://i.imgur.com/tlAKYDa.png[/IMG][/QUOTE]
This exact solution is why I've started work on CAMI. It's terrible and it can be done better.
[editline]4th March 2015[/editline]
[QUOTE=`impulse;47258924][url=https://github.com/FPtje/DarkRP/commit/870d793b0c56867e1966e926168c79d83ad8935d]This is the fix [b]YOU[/b] created[/url]
It works, it makes sense, it fixes the problem. The problem was that you didn't fall back to the default functions to check whether or not the user has access. You didn't account for custom user groups. I made that initial pull request fully expecting for it to be denied, and having the issue fixed the right way by you; I'm not going to sit there and try to figure out how the hell FAdmin works when you could do it in five minutes, easy peasy.
You say that there's no solution to said problem, but you've done it already. You ask the user to assign said permissions in a user group that's created in FAdmin, and if the player matches the user group, you do whatever needs doing. It's not hard to ask the player what action they want a user group to have access to.
Instead of clogging up admin mods with another interface that they have to follow (which could affect major parts of said admin mods depending on how they're written/structured), you could use the readily available functions. There's also no guarantee that admin mods are going to implement this interface so they can't use it reliably. Which means that they have to add a fallback [i]anyway[/i].[/QUOTE]
Right, now you can only customise the permissions for editing doors, running rp_job commands and seeing the logs if you have FAdmin installed.
Don't want FAdmin? [B]Fuck you I can't support every single other admin mod.[/B]
Want another admin mod but also keep FAdmin? [B]Fuck you, incompatibilities cannot be solved unless I hardcode conditions for every single admin mod.[/B]
I wouldn't have to say fuck you if there was a thing like CPPI for admin mods.
You, and maybe a small handful of addons need this. If you're making a gamemode that comes with an admin mod and you're fully aware that your admin mod is most likely going to be ran with another one, why not fix compatibility issues with your admin mod instead of making every one else fix theirs?
You need only save what user groups can access what commands; the admin mods can set the user groups themselves so you can use it. If you need to do it otherwise because your admin mod might be ran by itself without the existance of another one, then I don't understand why you would want both. It's akin to having two anti-viruses installed on your computer - it makes no sense and is obviously going to conflict.
Why is FAdmin included with DarkRP? Surely it would make sense to give people the choice of which admin mod they wish to use?
We don't expect you to support ServerGuard yourself, but we do expect you to use/fallback to the native GMod functions when running into ranks that aren't known to your gamemode.
[QUOTE=Alex_grist;47259032]Why is FAdmin included with DarkRP?[/QUOTE]
One of the reasons is because there is no abstraction from all admin mods that I can use in DarkRP. This thread isn't about why FAdmin is in DarkRP by default. Do not derail this discussion.
You also have multiple places that are setting user groups, it seems like you're fighting with your own admin mod with your own gamemode.
[IMG]http://i.imgur.com/MWS3cpq.png[/IMG]
It's not derailing, the main cause of this specific proposal is because an admin mod is included with DarkRP and causes incompatibility issues with other admin mods.
[QUOTE=Alex_grist;47259032]GMod functions when running into ranks that aren't known to your gamemode.[/QUOTE]
GMod functions do not provide a permissions system.
[editline]4th March 2015[/editline]
[QUOTE=Alex_grist;47259066]You also have multiple places that are setting user groups, it seems like you're fighting with your own admin mod with your own gamemode.
[IMG]http://i.imgur.com/MWS3cpq.png[/IMG][/QUOTE]
Alright, now you've just gone to personal attacks. That's a user config alternative and has nothing to do with admin mods whatsoever. Please do not derail this discussion into "NUH UH LOOK WHAT YOU'VE DONE YOURSELF" attacks.
[editline]4th March 2015[/editline]
[QUOTE=Alex_grist;47259066]
It's not derailing, the main cause of this specific proposal is because an admin mod is included with DarkRP and causes incompatibility issues with other admin mods.[/QUOTE]
[url=http://forums.ulyssesmod.net/index.php?topic=3779.0][B]Bullshit[/B][/url], also, personal attack.
why darkrp is so tightly coupled with an admin mod anyway?
[QUOTE=DarKSunrise;47259102]why darkrp is so tightly coupled with an admin mod anyway?[/QUOTE]
It isn't, it can be disabled. Please don't derail this thread about DarkRP and FAdmin.
[QUOTE=FPtje;47259107]It isn't, it can be disabled. Please don't derail this thread about why DarkRP and FAdmin.[/QUOTE]
This whole thread was sparked entirely because of your issues with FAdmin/DarkRP and other admin mods.
Either way, as I've said before, running multiple admin mods is a silly thing to do in the first place. You shouldn't do that because it most obviously causes compatibility issues. People still do it anyway because each admin mod has features that the other one doesn't. It's up to the maintainers of the admin mods to implement these features so they don't have to run both at the same time.
Sorry, you need to Log In to post a reply to this thread.
