This is because the recommended method ('owner ircquote nickserv register mypassword bot@example.com')
does not work on charybdis, as Limnoria inserts a colon
before the trailing argument and Charybdis' m_alias module
does not parse commands using the IRC syntax, so it
considers the leading colon to be part of the email address.
The alternative would be to change the recommended command to:
'owner ircquote PRIVMSG nickserv :register mypassword bot@example.com'
but it is prone to typos, so I think we should avoid it.
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>
