Until now, only `waitingJoins` was stored separately per network, while
`channels`, `sentGhost` and `identified` had one common value per plugin
instance. Instead of making everything a dictionary indexed by network
name like `waitingJoins`, let's bundle all the state together in a class
and store *its* instances in such a dictionary.
This fixes at least one race condition, for which a test case was added.
Even with `noJoinsUntilIdentified` set, the bot would let joins through
as long as *any* one network has already finished identifying.
- 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.
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>
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.
Notify the user when trying to use the commands on a disabled network, ignore
noJoinsUntilIdentified, and don't try communicating with services.
Closes: Sf#3018464
Signed-off-by: James Vega <jamessan@users.sourceforge.net>
(cherry picked from commit 9e73f4482c)
Notify the user when trying to use the commands on a disabled network, ignore
noJoinsUntilIdentified, and don't try communicating with services.
Closes: Sf#3018464
Signed-off-by: James Vega <jamessan@users.sourceforge.net>
