Bug 100369 - Private messages sent from channel contexts should be logged in the appropriate query log instead of the channel's log
Summary: Private messages sent from channel contexts should be logged in the appropria...
Status: CONFIRMED
Alias: None
Product: konversation
Classification: Applications
Component: logging (show other bugs)
Version: 1.5-rc1
Platform: unspecified Linux
: LO normal
Target Milestone: ---
Assignee: Konversation Developers
URL:
Keywords:
: 245752 265950 (view as bug list)
Depends on:
Blocks: 192524
  Show dependency treegraph
 
Reported: 2005-02-27 14:04 UTC by JPD
Modified: 2021-03-11 02:28 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description JPD 2005-02-27 14:04:25 UTC
Version:           0.16 #2075 (using KDE 3.3.2, Gentoo)
Compiler:          gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)
OS:                Linux (i686) release 2.6.10-gentoo-r6

Logging behaves inconsistently in regards to /msg's. I was told this was to protect dolts from having their nickserv passwords logged. I feel that is making a decision for the user which should be left to the user. Additionally dolts are still not protected from having their nickserv passwords logged because /msg's are logged, or at least the echo from them, in whatever window you send them from, example follows:
[Sun Feb 27 2005] [13:36:22] <cartman> interesting
[Sun Feb 27 2005] [13:36:25] *-> nickserv* hello this is just a test

That is from my logfile for #konversation. I think there are several ways to fix this bug going from simple to complex, all of which are superior to current functionality:
a) Log everything
b) (a) but censor messages to services
c) (a) + (b) but have services in a user configurable list of nicknames to censor: this allows users to censor nicks other than just services, ie: the person with which they are having an affair
d) (a), (b) or (c) but with pattern matching on what messages to censor, ie only the ones containing passwords.

Additionally I have heard concern for people wanting to have automated script sent messages not logged. Well there are two ways around this, either use /raw calls or impliment a /qmsg or some other alias for "quiet message" or whatever you wish to call it.
Comment 1 John Tapsell 2006-01-17 14:09:42 UTC
You can use /query person    to have it logged.
Actually the fact that /msg  is still logged in the channel you do it in is actually quite bad.

Maybe what we should do is simply have a list of nicks that aren't logged at all, then ship with the defaults of nickserv  and whatever other popular password nicks are.  If we do this then we could log /msg as well.
Comment 2 Torrie Fischer 2006-03-10 00:34:51 UTC
I was thinking that perhaps you could log the /msgs to the same logfile a query window would use.
Comment 3 Peter Simonsson 2011-02-10 08:06:49 UTC
*** Bug 265950 has been marked as a duplicate of this bug. ***
Comment 4 Eike Hein 2011-06-27 13:20:09 UTC
*** Bug 245752 has been marked as a duplicate of this bug. ***
Comment 5 Nicolás Alvarez 2012-04-09 02:12:26 UTC
Git commit 00c0709eaac0fbe9798bd7141e6a94ac68a54156 by Nicolás Alvarez.
Committed on 09/04/2012 at 04:11.
Pushed by nalvarez into branch 'master'.

Fix misleading log formatting when /msg'ing from a channel window.

When doing "/msg foo bar" in a channel, we used to log "<foo> bar"
in the channel log. This is very misleading, since it looks as if
'foo' said it rather than sending it *to* foo. This commit changes it
to "<-> foo> bar", which looks a bit odd to me but it's consistent
with what gets shown in the ircview.

This partially fixes the complaints in bug 100369. The other part of
that bug is logging the message in the recipient's log
instead of the channel's, but that's apparently quite hard.

M  +5    -1    src/viewer/ircview.cpp

http://commits.kde.org/konversation/00c0709eaac0fbe9798bd7141e6a94ac68a54156
Comment 6 Myriam Schweingruber 2013-04-14 01:54:05 UTC
Nicolas, any news on this for the upcoming 1.5 version?
Comment 7 Eike Hein 2013-04-14 17:35:22 UTC
This is still an issue.