This check was erroneously removed when fixing /mode #channel f when +f is
mlocked. Mlock checks were restricted to the places requiring chanops
(other than viewing +eI lists); cmode +L/+P do not require chanops, but
still constitute a mode change that must be checked against mlock.
After a change for dynamic server capabilities, the code to send out mode
changes was changed to use the capabilities belonging to the last mode
being sent out. This does not make sense; therefore, just use no
capabilities and remove supporting infrastructure.
Fixes compilation warning about losing const qualifier in assignment to
non-const variable
(cherry picked from commit 6d9c3f50944e1da3bf3a1be6454f85d6d6f7ab37)
s_assert requires some higher-level functionality that shouldn't be
present in ircd_defs.h. ircd_defs.h is used by ssld, which has no notion
of logging or sending IRC messages. Additionally, some of the headers
s_assert depends on result in conflicting definitions in ssld.c.
This change also fixes the compile when using --enable-assert=soft.
Check mlock at the same point where chanops are checked (except for
querying a +e/+I list) and abstract this check into a function.
In particular, /mode #channel f is now again allowed if +f is mlocked.
This used to be only advertised if a service was linked, which made
sense in ratbox when +r was only settable if services were available.
Now, however, +r is always available and so should always be advertised.
nenolod gave the thumbs-up to port ircd-seven banfowards to charybdis to spb
for a while, and people have asked about it. Might as well do it since it's a
slow weekend.
Note that as a side effect use_forward is removed from the config and
unconditionally enabled!
While what chanroles are trying to accomplish is a good idea, it is
apparently unclear this is the proper way to do it. Until we figure out
the exact way we wish to do this, it should be reverted for now.
The theory behind this is that services sends an ENCAP * GRANT #channel
UID :+flagspec message specifying the chanroles the user has. They are
mapped into flag bits and applied to the membership of the user. They
then are restricted or permitted to what they can do based on the
permissions mask regardless of rank.
For backwards compatibility, the default permission bit (without a GRANT
statement) allows a user to to anything an existing op can do ONLY if
they are an op.
Todo: make CHANROLE_STATUS work (the ability to apply +ov to people),
which is at the moment controlled by CHANROLE_MODE.
Do not allow a user to op themselves if they are
already opped, as "already opped" could be because
of OMODE's hack which will be unconditionally
reverted after the mode change.
Also, this matches old behaviour for users not
being able to generate mode changes redundantly
opping themselves.
Note that this change should only be taken advantage
of if all servers run patched code. Otherwise, mode
changes will be silently dropped and a desync
results.
Additionally, attempting to use too many modes or two times
the same letter is now detected and prevented.
Modules now request that a channel mode be added/orphaned,
instead of ugly manipulation from which that request had
to be guessed.
Slight changes are needed to modules that provide channel modes.
From the old API, one important function has been made static,
the other important function has been renamed, so loading old
modules should fail safely.
Special modes like +j can be tracked easily just by adding the necessary
code to parse them to set_channel_mlock(). This will cover propagation
as well.
