Re: Attachment spam: do we want to edit history?
Ralf Schlatterbeck <[email protected]>
| Newsgroups | gmane.comp.bug-tracking.roundup.user |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Sep 06, 2012 at 10:39:40AM -0400, John P. Rouillard wrote: > >I've just written a script to completely remove file spam: > >http://roundup.hg.sourceforge.net/hgweb/roundup/roundup/rev/9f507a042c1b > > By remove do you mean unlink? IIRC you can do unjournalled changes > from the api, so I assume this unlink is not recorded? Or is it just > deleted in the next step? I'm editing the journal, i.e. this changes history. I'm first removing the offending files if still attached to the issue, this *will* generate a journal entry, but then I'm removing all journal information that links to the file. If a journal record is empty after this I'm removing it. So this doesn't leave any traces on the issue that the file was there. > >Do we really want to edit history in this way? > >I'm for it (for spam only). > > I am also for it, but I think it would be good to leave some sort of > journal entry in the ticket to indicate that a file was removed due to > spam. The offending file object is still in the database and indicates that it was once linked to the issue. > I haven't worked with the journal api in a looong time. Is there a way > to generate a journal entry that is just pure text and has no relation > to any objects? Ideally if you look at the journal it should say > something like: > > date user "file number so and so removed - attachment spam" > > whithout any hyperlinks inside the " enclosed part for a web spider to > crawl. I don't know. > This would provide the audit trail entry at least so if somebody > really really wanted to, they could manually construct the uri for the > file and get date and user who created the spam and other attachment > info (maybe original size??) although not contents as they are zeroed > out. The file object is still in the DB. > I agree with your caution of removing mistakes without noting the > change, but I think this would be a suitable workaround if the code > allows it. Yes, lets hear what others think before taking any actions that can't be undone. Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: http://www.runtux.com Reichergasse 131, A-3411 Weidling email: [email protected] osAlliance member email: [email protected] ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/