Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#395 ChannelLogger disable logging per channel et al w/ patch

closed
James McCoy
5
2012-12-31
2008-02-28
John Rouillard
No

This diff adds the following parameters/functionality to ChannelLogger
1) new config per channel variable
'stripInitialChannelChars'. When the channel
is logged, the directory name has these chars
stirpped from the beginning. The default
value is '#' and make directories named
"channel" rather than "#channel" for the
logs. (since # looks ugly in names and is a
comment char under unix.)

2) New per channel variable outputMode which
doesn't implement anything at the moment but
is intended to allow ChannelLogger to log
with it's current text output or to setoutput
format to html to make prettier logs that can
be served via http. (The <>'s around
nicknames in the text version of the log file
sometimes behave wierdly in a browser.)

3) New per channel variable "logChannel" that
will disable logging by supybot in that
channel. Setting

 supybot.plugins.ChannelLogger.logChannel.#sys false

 will disable logging in the channel #sys.

Feel free to skip the patch for #2 (it's just a
call to conf.registerChannelValue(ChannelLogger,
'outputMode',....), but it may give somebody ideas
and the impetus to fill in the code (well I can
dream right?).

The logChannel patch is quite useful when you want
to use supybot to auto-op, or some other functions
but not have it log the channel, and the
stripInitialChannelChars has made navigating
easier for my users.

Thanks for considering this patch.

-- rouilj

Discussion

  • John Rouillard
    John Rouillard
    2008-02-28

    Diff against supybot 0.83.3 ChannelLogger

     
    Attachments
  • James McCoy
    James McCoy
    2009-03-08

    The ability to disable logging on a per-channel basis will be available in the next release via the ChannelLogger.enable channel variable. Part 1 of the suggested patch won't be added as that can cause filename conflicts. Part 2 won't be added (for now) because there are no other formats for logging. If the plugin gains other logging formats, I'd reconsider.