This is a practice already used by some networks including freenode. It
makes it possible to distinguish user part messages and forced parts
such as /remove.
ref: atheme/charybdis@a0b4a9216d
Merge of commit da2fc2cbdec471b516a2aa56ed9f3513da8df87c in master
The behavior of cutting at the first '~' is confusing at first, and
looks too much like a bug.
atheme/charybdis@96b89dce38
This is a lot like the previous channel owner mode patch, except the
documentation that previously said "admin" now says "owner" in comments.
src/channel: Kicking logic for owner mode fixed
src/channel: Document the kick/deop logic
decruft: remove temporary files
Do kick_on_split_riding if services sends an SJOIN
with a lower TS and a different key. This relies on
services restoring TS (changets option in atheme) and
services not immediately parting after receiving the
KICK, which is the case in recent atheme.
For invite-only channels, still only do
kick_on_split_riding in netbursts. Services is
assumed to handle this itself (atheme does).
Modeset files are modules stored in shadowircd/modes. All they do is initalize
a set of modes on load, and orphan said modes on unload.
All cmodes not included in ircd-ratbox are now located in modeset files, rather
than being in the core. These modes no longer simply use defines, their
locations are stored in a the new struct module_modes. Each of these is set
when intializing the mode in the modeset files, and set to 0 when orphaning
the mode upon unloading the modeset file.
In addition, use_forward has been removed, as it is now obsoleted by modesets.
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.
This has a separate enabling option channel::channel_target_change.
It applies to PRIVMSG, NOTICE and TOPIC by unvoiced unopped non-opers.
The same slots are used for channels and users.
* does not apply to NOTICE (as those may well be automated)
* mirrors +g behaviour so that no useless accept entries are added for services
* respects max_accept, if it would be exceeded the message is dropped with numeric 494
* check moved up so this is checked before floodcount/tgchange
Pulled from Charybdis upstream changeset 1388:b1ef26176350 done by jilles.
This shouldn't provide any way for a client to get on a CALLERID list
without authorization, as if a client is +g already, a CTCP request, for
example, won't be replied to.
Such bans are not applied locally, but are propagated normally.
They can only be removed on a server that applies them.
Note that normally KLINE will not accept such bans.
This is mainly for services, differing min_wildcard and
ircd changes.
Sam Dodrill
JD Horelick
Jilles Tjoelker
William Pitcock
B.Greenham
alxbl
B.Greenham
Stephen Bennett