[.BadGurl AKA FallenAngel]

Just use the admin overrides file to make commands for custom flags, I use one to make skins available to public players by using the 'p' flag and then just assign the flag to the player (or group) on sourcebans.

Your admin overrides text file would look like this..

Overrides { /** * By default, commands are registered with three pieces of information: * 1)Command Name (for example, "csdm_enable") * 2)Command Group Name (for example, "CSDM") * 3)Command Level (for example, "changemap") * * You can override the default flags assigned to individual commands or command groups in this way. * To override a group, use the "@" character before the name. Example: * Examples: * "@CSDM" "b" // Override the CSDM group to 'b' flag * "csdm_enable" "bgi" // Override the csdm_enable command to 'bgi' flags * * Note that for overrides, order is important. In the above example, csdm_enable overwrites * any setting that csdm_enable previously had. * * You can make a command completely public by using an empty flag string. */ "sm_admins" "b,z" //Only admins & owners to view online admins "om_admin_credits" "z" //Owners only "sm_god" "z" //godmode "sm_noclip" "z" //noclip "sm_models" "b,p" //skins }

[rhelgeby]

Perhaps it's suitable for commands, but some plugins also have actions or events and need to implement their own set of permissions.

Plugins could just use custom flags to control permissions to specific features, but that may conflict with the same flag in other plugins where you want access to one feature in one plugin, but not in another plugin.

[asherkin]

Originally Posted by rhelgeby Perhaps it's suitable for commands, but some plugins also have actions or events and need to implement their own set of permissions.

Which should be mapped to a string that can be used with both regular and admin group overrides (which allow both a flag as in regular overrides, along with specific "allow" or "deny" access) with CheckCommandAccess.

[rhelgeby]

So we could just make fake command strings like "myPlugin.myFeature" and override those instead? Though they would still need to be mapped to flags. In some cases it would be enough to just be a member of a group.

[asherkin]

Originally Posted by rhelgeby So we could just make fake command strings like "myPlugin.myFeature" and override those instead? Though they would still need to be mapped to flags. In some cases it would be enough to just be a member of a group.

Yes, although I'd advise using all lowercase and underscores to fit in with everything else (although then they might be confused with commands).

As for default flag mapping, it's just a matter of making sane choices (if it's a public plugin, else just go wild as you know how you'll be setting up overrides).

Some simple default recommendations (for things that don't have a sane equivalent flag of their own):
Public: 0
Any admin: Generic
No-one: Root

One silly thing some people do that could screw this up: Give other people the Root flag.
It's basically designed as a complete override to the admin system, for the server console.

[Dr. McKay]

Originally Posted by asherkin One silly thing some people do that could screw this up: Give other people the Root flag. It's basically designed as a complete override to the admin system, for the server console.

It amazes me when people post here saying that they give all their admins root because they don't want to set up permissions then they ask how to prevent admins from doing x or y.

[Smarmy]

Originally Posted by Dr. McKay It amazes me when people post here saying that they give all their admins root because they don't want to set up permissions then they ask how to prevent admins from doing x or y.

It's like the process of elimination, done admin permissions style.

Give everyone all permissions and then find out who will abuse what and only remove those permissions from said abusive admins.