- Adjust _chanRe to only match channels, as atheme also puts the target nick in bold
- Look for "unbanned <botnick>" messages in ChanServ notices (after stripping formatting)
This likely fixes GH-166. atheme has been using this format since at least 2005[1],
so it's possible that Supybot's rejoin-on-ban had never worked with it.
[1]: 4017c0da85 (diff-ba2bdc02ba7b29fd7e4931cafe63baa0R218)
On Atheme, Anope, and oftc-ircservices, /cs unban, invite, op, and voice
implicitly assume the caller if no nick is given. However, certain combinations
such as /cs invite *with* a nick are not supported on atheme per
https://github.com/atheme/atheme/issues/568, and cause rejoin-on-kick to +i
channels to fail.
This fixes one part of GH-1118.
* Most of networks have services with this name.
* I can only name QuakeNet from those that don't, but the default
configuration exludes it.
* If this plugin is loaded in Supybot-wizard, it asks for nicknames of
NickServ and ChanServ.
[SKIP CI] because this is `git commit --amend` and the build already
passed.
When noJoinsUntilIdentified config is true, the bot holds join messages in a 'waitingJoins' list, and processes them
once nickserv identification comes through. The problem was that when the bot is configured to join multiple networks,
join messages from different networks would get appended to the same list, without any differentiation by which message
belongs to which network. Thus, if there are messages waiting for multiple networks, it would often be the case that
whichever network got identification done first, would 'pick up' other network's join messages.
This fix stores the network name along with the join messages in the list, and has each network pick out only its own
join messages.
Conflicts:
src/version.py
Signed-off-by: James McCoy <jamessan@users.sourceforge.net>
Conflicts:
plugins/Services/plugin.py
When noJoinsUntilIdentified config is true, the bot holds join messages in a 'waitingJoins' list, and processes them
once nickserv identification comes through. The problem was that when the bot is configured to join multiple networks,
join messages from different networks would get appended to the same list, without any differentiation by which message
belongs to which network. Thus, if there are messages waiting for multiple networks, it would often be the case that
whichever network got identification done first, would 'pick up' other network's join messages.
This fix stores the network name along with the join messages in the list, and has each network pick out only its own
join messages.
Conflicts:
src/version.py
Signed-off-by: James McCoy <jamessan@users.sourceforge.net>
Richard