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
When a client tries to part from a channel to which it was fixed, we sent it a
join again to make it rejoin (bad irssi for not waiting for the server's reply
to PART!).
The problem here was that we didn't send the nicklist and thus the channel
appeared empty. This fixes SF.net #2802684.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1731 726aef4b-f618-498e-8847-2d620e286838
Before this, the KICK message was missing a target which was kicked.
Now the user kicks himself. :)
Thanks to JoeK for reporting this bug.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1486 726aef4b-f618-498e-8847-2d620e286838
That false/true thing makes no sense and pUser was passed in to a bool
argument which means it was always true... weird...
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1472 726aef4b-f618-498e-8847-2d620e286838
OnUserAttached is renamed to OnClientLogin and
OnUserDetached to OnClientDisconnect.
This adds some new function with different arguments for the old names to cause
warnings from -Woverloaded-virtual while compiling.
This patch also adds OnClientConnect() which is called when the low-level
raw connection is established. (No SSL-handshake was done at this point yet!)
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1266 726aef4b-f618-498e-8847-2d620e286838
This was found via default channels (LoadModule = partyline ~#chan).
- Always use a valid (=non-empty) server name
- If a user is not connected to IRC, all clients might have a different idea of
the current nick. Handle this for SendNickList() via a new function
PutUserIRCNick() that uses the irc nick if we are connected to IRC and else
correctly uses the nick that clients thinks it curretnly has.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1141 726aef4b-f618-498e-8847-2d620e286838
