This document is intended to illustrate how the improved form of insp's oper privilege setup would look like.

Firstly, we rename oper classes to 'flags'. There's two reasons for this:

1. People moving from unreal 3 will be used to class in relation to client connections, eg class::sendq and so forth.
2. Using 'class' and 'type' for two different things is just confusing. (Does X go in a class or a type?) Especially confusing for those trained to think of 'class' and 'type' as basically synonyms (which they kinda are).

As for the flag block itself, it will have as many as four optional blocks, plus any others added by modules. Optional blocks not given should default to empty, giving no extra permissions.

• commands {}: List of commands that the oper can use. We could theoretically check this list for missing commands and issue warnings, but if so, do that only after all modules load.
• usermode {}: List of usermodes the oper can set on himself. As with commands, this list could be checked for missing modes. Also, note that modes like 'o' are pointless and should trigger a warning. (Note: this could probably be done with a string value instead.)
• chanmode {}: List of channel modes the oper can set on channels. This only satisfies one requirement of such modes (must be an ircop with the listed mode): it doesn't grant the oper to set the mode without channel operator status, for example (that requires something like m_override). (Note: this could probably be done with a string value instead.)
• misc {}: List of miscellaneous privilege tokens, can be used for privileged form of commands, like remote kill or squit. Also modules could add simple on/off privilege tokens that aren't commands here. These generally have to be manually checked for in code. If a whole command is controlled by a token, then instead the command name itself goes in commands {}.

In general, a token of * should be treated like 'all'. So eg, any command check, usermode check, chanmode check, or misc token check would succeed if a * token was anywhere in the appropriate block. As a possibility: treat -<token> as “does not have this privilege”, so doing things like *; -DIE; -RESTART; could be done to mean “all commands except DIE and RESTART”. Also, of course, * could be explicitly checked for, but generally stuff should have a token they check for, and let * mean “all tokens” rather than “all tokens plus some hidden stuff”. Again, other modules could add more stuff, like m_override can add override {} block.

Here are some example flag blocks:

flag ban {
	commands {
		KLINE; # Not case sensitive. But uppercase is generally preferred form, like in real protocol.
		GLINE;
		ELINE;
		ZLINE;
	};
};

flag can_setq {
	usermode {
		q; # Case sensitive!
	};
};

flag can_set_oper_only {
	chanmode {
		O;
	};
};

flag can_remote_kill {
	misc {
		remote-KILL; # As opposed to commands, misc tokens should be lowercase, and use - as word
		             # seperator. Exception is where part of token is indicating effect on a command
		             # in which case part that names command should be uppercase. Can be case
		             # sensitive or not (haven't decided, leaning toward not).
	};
};

flag can_banwalk {
	override {
		banwalk;
	};
};

flag can_do_everything {
	commands { *; };
	usermode { *; };
	chanmode { *; };
	misc { *; };
	override { *; };
};

The rest is pretty much the same. Assign flags to types and go.

type I_love_to_abuse_oper_powers {
	flags { can_do_everything; };
};

Here is how u3 oper setup might look in this style:

flag can_rehash { commands { REHASH; }; };
flag can_die { commands { DIE; }; };
flag can_restart { commands { RESTART; }; };
flag can_localkill { commands { KILL; }; };
flag can_wallops { commands { WALLOPS; }; };
flag can_globops { commands { GLOBOPS; }; };
flag can_localroute { commands { CONNECT; SQUIT; }; };
flag can_globalroute { misc { global-CONNECT; global-SQUIT; }; };
flag can_localkill { commands { KILL; }; };
flag can_globalkill { misc { global-KILL; }; misc { kill-SPAMFILTER; }; };
flag can_kline { commands { KLINE; }; misc { add-KLINE; kline-SPAMFILTER; }; };
flag can_unkline { commands { KLINE; }; misc { remove-KLINE; }; };
flag can_localnotice { misc { broadcast-server-NOTICE; }; };
flag can_globalnotice { misc { broadcast-network-NOTICE; }; };
flag can_zline { commands { ZLINE; }; misc { zline-SPAMFILTER; }; };
flag can_gkline { commands { GLINE; SPAMFILTER; SHUN; TEMPSHUN; }; misc { gline-SPAMFILTER; shun-SPAMFILTER; tempshun-SPAMFILTER; }; };
flag can_gzline { commands { GZLINE; }; misc { gzline-SPAMFILTER; }; };
flag can_override { override { *; }; };
flag can_setq { usermode { q; }; };
flag can_addline { commands { ADDLINE; }; };
flag can_dccdeny { commands { DCCDENY; UNDCCDENY; }; misc { dccdeny-SPAMFILTER; }; };

flag can_sacommand { commands { SAJOIN; SAMODE; SAPART; }; };
flag can_beatup_protected { misc { override-umodeq; service-KILL; }; };
flag can_global_rehash { misc { remote-REHASH; }; };

type local {
	flags {
		can_rehash;
		can_globops;
		can_wallops;
		can_localroute;
		can_localkill;
		can_kline;
		can_unkline;
		can_localnotice;
	};
};

type global {
	flags {
		inherit local; # Possible thing we could add to make chains of types
		               # like u3-style easier to manage?
		can_globalroute;
		can_globalkill;
		can_globalnotice;
	};
};

type admin {
	flags {
		inherit global;
		can_dccdeny;
	};
};

type service-admin {
	flags {
		inherit global;
		can_dccdeny;
		can_setq;
		can_sacommand;
	};
};

type netadmin {
	flags {
		inherit admin;
		inherit service-admin; # Multiple inheritance allowed to pull in multiple sets of privileges,
		                       # same flag in both is just redundant. (Maybe?)
		can_beatup_protected;
		can_global_rehash;
	};
};

As demonstrated, a useful feature might be to allow one type inheriting the flags from a pervious type. Possibly with multiple inheritance. Not hard to deal with: same flag appearing more than once is just redundant, but no error or warning.

### Revision 22 July 2007 ###

This part contains some changes I've considered in response to http://bugs.unrealircd.org/view.php?id=3475

In core distribution, I've found the following modules add data to oper setup:

• m_oper_hash.cpp - Adds oper::hash
• m_operlevels.cpp - Adds type::level
• m_opermodes.cpp - Adds type::modes
• m_override.cpp - Adds type::override (See above: this goes in flags {} now.)
• m_swhois.cpp - Adds type::swhois, and oper::swhois

Also from core we get type::host

Also, inherit is moved to toplevel of type, and inherits everything, not just flags.

Finally, add type::display, to indicate how the oper should appear in whois. If not given, it defaults to the type's name (or a display pulled in by inherit, if used).

Here is what those things would generally look like. This is a mostly complete look at how flag, type, and oper should all come together:

flag stuff {
	commands { *; };
	usermode { *; };
	chanmode { *; };
	override { *; }; # <- Goes here instead of type, otherwise, from m_override.cpp
};

flag all_misc {
	misc     { *; };
};

type some_oper {
	flags {
		stuff;
	};
	host "Oper.MyNetwork.net";
	display "Silly Operator";
	modes "+qsn *"; # <- from m_opermodes.cpp
	level 9000; # <- from m_operlevels.cpp
	swhois "is silly"; # <- from m_swhois.cpp
};

type some_oper_with_misc {
	inherit some_oper;
	flags {
		all_misc;
	};
	level 9999;
	swhois "is \002very\002 silly"; # <- Will we even have escape codes like this? Could be useful.
};

# The above is equivalent to:
# type some_oper_with_misc {
# 	flags {
# 		stuff;
# 		all_misc;
# 	};
# 	host "Oper.MyNetwork.net";
# 	display "Silly Operator";
# 	modes "+qsn *";
# 	level 9999;
# 	swhois "is \002very\002 silly"; # <- Will we even have escape codes like this? Could be useful.
# };

oper sillyop {
	password "<junk>";
	hash "md5"; # <- From m_oper_hash.cpp
	host { # <- Equivalent to u3's from::userhost, probably should rename to allowed-hosts or something.
		"sillyop@host.isp.com";
	};
	type some_oper;
};

oper verysillyop {
	password "<junk>";
	hash "md5";
	host {
		"verysilly@3ffe::0/16";
	};
	type some_oper_with_misc;
};

oper sillyadmin {
	password "<junk>";
	hash "md5";
	host {
		"*@localhost";
		"*@127.0.0.0/8";
		"*@::1";
	};
	type some_oper_with_misc {
		display "Silly Admin";
		host "Admin.MyNetwork.net";
		level 99999;
	};
};

# The above is equivalent to:
# type _anon_1 {
# 	inhert some_oper_with_misc;
# 	display "Silly Admin";
# 	host "Admin.MyNetwork.net";
# 	level 99999;
# };
# oper sillyadmin {
# 	password "<junk>";
# 	hash "md5";
# 	host {
# 		"*@localhost";
# 		"*@127.0.0.0/8";
# 		"*@::1";
# 	};
# 	type _anon_1;
# };

When inheriting multiple types, the value of single-value options like type::host, type::display, or type::level will be whatever is set by the last type inherited, unless overriden by the type doing the inheriting. For example, if type X sets display to “Spambot Buster”, and type Y sets display to “Netsplit Fixer”, inherit X; inherit Y; yields a display of “Netsplit Fixer” whereas inherit Y; inherit X; yields “Spambot Buster”, and inherit X; inherit Y; display “Admin”;, no matter where the display is in the order, will yield “Admin”. In all three cases, the resulting type will have all the privileges set in both X and Y, plus any it sets for itself.

(wikified, with some adjustments, from http://aquanight.dyndns.org:2080/~aquanight/u4-opertype-style.txt)