The behavior of IRC clients is unpredictable if they don't get the
appropriate CHANTYPES for partyline channels. Thus, send RPL_ISUPPORT
with the appropriate CHANTYPES also when a client is not connected to
a network, or when the network is not connected to IRC.
The following people agreed with the change, in alphabetical order:
(people who approved in several ways are listed only once)
By email:
- Adam (from Anope)
- Austin Morton
- Brian Campbell
- Christian Walde
- Daniel Holbert
- Daniel Wallace
- Falk Seidel
- Heiko Hund
- Ingmar Runge
- Jim Hull
- Kyle Fuller
- Lee Aylward
- Martin Martimeo
- Matt Harper
- Michael J Edgar
- Michael Ziegler
- Nick Bebout
- Paul Driver
- Perry Nguyen
- Philippe (cycomate)
- Reuben Morais
- Roland Hieber
- Sebastian Ramacher
- Stefan Rado
- Stéphan Kochen
- Thomas Ward
- Toon Schoenmakers
- Veit Wahlich
- Wulf C. Krueger
By IRC:
- CNU
- Jonas Gorski
- Joshua M. Clulow
- Prozac/SHiZNO
- SilverLeo
- Uli Schlachter
At https://github.com/znc/znc/issues/311 :
- Alexey Sokolov
- Elizabeth Myers
- flakes
- Jens-Andre Koch
- Jyzee
- KindOne/ineedalifetoday
- Lee Williams
- Mantas Mikulėnas
- md-5
- Reed Loden
At the last few pull requests' comments:
- Allan Odgaard
- Jacob Baines
- Lluís Batlle i Rossell
- ravomavain
- protomouse
The following commits' authors didn't respond:
Trivial changes:
- f70f1086fd
- 4ca8b50e45
The changes which are not presented in master anymore:
- 5512ed2ea0
- 960a4498f7
- 0f739de2c0
- 7f53cc810bFix#311Fix#218
This means that every reference to my own user will instead show my
clients nickname. This will prevent the client from seeing itself, and
the real nick for your client in the channel.
Send private partyline messages to each client seperately using the
correct nickname for that client. It may differ if they are user clients
or network clients where they are not connected to an IRC server.
I have created macro's for the nickname prefix so this could easily be
changed.
Use 401 instead of 403 for user/channel not found
Fixes#21
This fixes#96. When the last user in a partyline channel is deleted, the
channel is deleted, too. This invalidates the iterator used in OnDeleteUser().
This fix is to increase the iterator before the channel can be deleted.
After the above fix, znc still crashed due to another broken use of iterators.
When a network is deleted, it takes all its clients with it (why aren't they
just moved into the "no network"-state?"). However, deleting a CClient removes
it from the network's list of clients via CClient::Disconnect(). This resulted
in another invalid use of iterators.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There are apparently "IRC" daemons (which don't deserve that name) that don't
send any 005. Yes, I'm looking at you, chat.wikileaks.org. For these servers we
shouldn't inject partyline's channel prefix because that makes us send out a
"CHANTYPES=~" line which severely confuses clients. XChat then turns everything
into a query!
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2162 726aef4b-f618-498e-8847-2d620e286838
"virtual host" seems to be confusing to users since they wonder why
i.am.superman doesn't work. Let's rename this to "bindhost" and perhaps it
becomes clearer what this setting does.
Thanks to SilverLeo!
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2113 726aef4b-f618-498e-8847-2d620e286838
If the CHANTYPES token was the last one in a 005 numeric, partyline would call
std::insert() with CString::npos for the position to insert at. This throws a
std::out_of_range error. Fix this by using CString::append() in this case.
Thanks to Superfly_ for the bug report and helping me reproduce this.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2087 726aef4b-f618-498e-8847-2d620e286838
