The u2.10.11 server (still in beta--we have a crash in s_conf.c somewhere)
allows an operator to use /opmode and /clearmode to manipulate modes on a
channel. Admins may wish to restrict operators from manipulating modes on
certain channels. Thus, I'm looking for a volunteer to implement a new
feature. It will be needed for the u2.10.11 release.
My idea is that we'll reintroduce "Q"-lines (Quarantine lines) into the
.conf. The first field of the Q line will contain a channel name; the
second field will include a text message to be spat back to any operator
attempting to manipulate modes on that channel via /opmode or /clearmode.
I don't expect there to be many of these lines, so for a first cut, a
straight linked list is sufficient. I don't anticipate any other fields
being necessary.
Currently, operators can use /opmode or /clearmode if they have the
PRIV_OPMODE. This feature would require addition of a PRIV_FORCE_OPMODE,
to allow operators to override the Q-line restriction if need be. Because
u2.10.11's .conf does not support privileges (u2.10.12's does), a feature
will also be needed: FEAT_OPER_FORCE_OPMODE. I will leave it to your
discretion whether to allow local channels ("&" prefix) to be specified in
Q-lines--if you decide to implement this, PRIV_FORCE_LOCAL_OPMODE and
FEAT_OPER_FORCE_LOPMODE and FEAT_LOCOP_FORCE_LOPMODE will also be needed.
Finally, mo_opmode() and mo_clearmode() (NOT ms_opmode() or
ms_clearmode()!) will need to be modified to check Q-lines. If the
channel name is prefixed by a "!", then Q-lines will not be checked, but
the appropriate privilege (PRIV_FORCE_OPMODE or PRIV_FORCE_LOCAL_OPMODE)
must be checked. If the oper is attempting to use "!" to force the mode
change, and does not have the FORCE privilege, respond with
ERR_NOPRIVILEGES.
You may also, at your discretion, change the text of the ERR_NOPRIVILEGES
error message to reflect its current use--the current text says, "You're
not an IRC operator," but something like "You don't have permission to do
that" may be more appropriate.
As a final note, you must make certain that the documentation in
doc/example.conf and doc/readme.features is brought up to date with your
changes.
If you're interested in working on this, post here to the list. If more
than one person is interested, I would encourage all of you to collaborate.
Feel free to ask me questions, though I should note that my time is going
to be rather limited over the next few weeks). Please post diffs to
[EMAIL PROTECTED], but keep commentary on this list. Even if the diff
is not a final product, please make sure that it includes ChangeLog
documentation and a short description appropriate for a commit message.
Do feel free to add your name(s) to doc/Authors in an appropriate place.
Thanks,
--
Kevin L. Mitchell <[EMAIL PROTECTED]>
