Bantracker redesign

[Dennis Kaarsemaker]

On di, 2008-04-08 at 01:02 +0200, Lorenzo J. Lucchini wrote:

> > Model:
> >
> > class OperatorAction(models.Model):
> >     when = models.DateTimeField("Time of action", auto_now_add=True)
> >     channel = models.CharField("Affected channel", maxlength=30)
> >     masks = models.TextField("Affected masks")
> >     ops = models.TextField("Active ops")
> >     log = models.CharField("Filename of log")
> 
> What is "Active ops" exactly? Is it different from "the op who did the 
> action"?
> 
> > class Comment(models.Model):
> >     action = models.ForeignKey(OperatorAction)
> >     when = models.DateTimeField("Time of comment", auto_now_add=True)
> >     who = models.ForeignKey(User)
> >     what = models.TextField()
> >
> > I do not want to store the log in the database, this to avoid database
> > explosion like what has happened with the old code.  For actions older
> > than a year(up for debate), the log will be deleted.
> 
> I'm not a big fan of the one-year-backlog thing.
> Sometimes very old bans *do* become relevant again.

We should have some sort of private wiki thing for discussing such bans.

> Besides, I think that by using the "one minute timer" trick, stored log sizes 
> will dramatically shrink; also, Python offers string compression, and I 
> really suspect that keeping logs compressed (whether in or out of the 
> database) would have a huge positive impact on space, and a negligible 
> negative impact on performance (at least unless you're going to provide 
> searching inside the logs).

String compression may help, that would just unconditionally serve the
data compressed. 

> > Import of old data
> > ------------------
> > For old data, the relevant fields will be imported. Most notably, the
> > 'ban removed by' field will go away. It has proven to be unreliable.
> > Logs older than one year will not be imported, actions will.
> 
> As Tony says, I think removals should be tracked by periodically looking at 
> the current ban list and check what bans are still relevant.

Ack.

> > Channels to track
> > -----------------
> > Currently bans in all channels are tracked. I'd like to limit that to
> > only a few core channels.
> >
> >  - #ubuntu
> >  - #kubuntu
> >  - #ubuntu-offtopic
> >  - #kubuntu-offtopic
> >  - #ubuntu+1
> >  - #ubuntuforums
> 
> OK, although I'd leave it as an option for channel contacts to request 
> logging.
>
> On a related topic, I think the bantracker should be publicly accessible 
> again, but with two important limitations for anonymous users: comments 
> should not be visible (or perhaps some specific comments could be tagged 
> as "sensitive"), and banmasks should be scrambled.

Define 'scrambled'. I agree that the bantracker must be public again,
which it will.

> I'd also still like a way to link actions together; the "one minute timer" 
> partially achieves that, I think, but still it would be nice to link ban 
> evaders or simply people who have a habit of changing nicknames.

Would be nice, could have a ManyToManyField for that.

> A similar effect could be achieved also by having the search function look at 
> comments, too, so one would simply have to mention the relevant 
> nicknames/mask in a comment to make the action show up in a related search.

As you said before, that negates the compression. Which do you think is
more important?
-- 
Dennis K.

The universe tends towards maximum irony. Don't push it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-irc/attachments/20080408/0de688b6/attachment.pgp>