[Konversation-devel] [Bug 100369] New: Inconsistent logging behavior for msg

[JPD]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=100369         
           Summary: Inconsistent logging behavior for msg
           Product: konversation
           Version: unspecified
          Platform: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: konversation-devel kde org
        ReportedBy: tightcode hotmail com


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.