The placement of the tail bytes field on the log page causes an extra line in the gray box at the top of the log. At least it does on the single machine that I'm testing on (1280x800 laptop). I think it makes better sense to have a <br /> after the wrap column and put the max tail bytes box there that way. You've already got 3 lines in the box due to the checkboxes on the right. Adding the tailbytes box as a second line after wrapping will just use existing blank space. also, the box size of 1 only displays 5 characters on this machine and the one I used when I submitted the code. Both IE8. a size of 2 lets you specifiy numbers bigger than 99999.
On Sat, Oct 17, 2009 at 12:14 PM, K Post <[email protected]> wrote: > Another thought on the MaxAllowedDups functionality. Does it make sense to > have an excluded subjects regex. We find that there's lots of "your order," > ,"re: ", "urgent reply needed" messages with very different content. If we > could have a list of subjects to keep even if there are dups, I think that > would help. > > > > On Sat, Oct 17, 2009 at 12:01 PM, K Post <[email protected]> wrote: > >> Wow - lots of changes! I'm really happy to see these! >> >> Is MaxKeepDeleted named properly? Shouldn't it just be KeepDeletedDays? >> Max implies that it's possible for the files to be deleted before that. >> Minimum isn't quite right because of the converse. If I'm understanding >> this functionality correctly, it'll remove the "deleted" files after that >> many days, not really max or min. >> >> Will MaxKeepDeleted apply also to the discarded folder? for those of us >> not putting bayesian spam to the spam folder that will help. >> >> I love that maxallowed dups doesn't operate on notspam, but does it make >> sense to have it operate on discarded too? Instead of putting the >> duplicates into discarded, what about a new folder called duplicates - or >> maybe instead a separate folder for bayesian spam (that can get manual >> scanning on occasion)? >> >> Last, it doesn't seem that maxAllowedDups will necessarily break block >> reporting now since we're still storing the duplicates. Yes? >> >> Such big changes for only a .01 version number increase. Thanks so much >> for the hard work and for considering my previous input on duplicate files, >> storange, and pairing. Your implementation is quite clever. >> >> >> >> >> On Sat, Oct 17, 2009 at 9:55 AM, Thomas Eckardt/eck < >> [email protected]> wrote: >> >>> Hi all >>> >>> fixed in 2.0.1_RC0.4.32: >>> >>> - EmailAdmins are unable to modify Blacklist via email interface >>> - text for helo blacklist in rebuild is not correct >>> >>> >>> >>> changed: >>> >>> - improvements in MaillogTail view: >>> - better definition of the search target (number of lines and files) >>> - used definitions are stored for AdminUsers (not root !!) and are >>> reused if the page reopened >>> - tail bytes are setable per session >>> - the defined values are no more reset to defaults after a search >>> >>> >>> new: >>> >>> 'MaxAllowedDups','Max Number of Duplicate File Names' 'The maximum >>> number >>> of logged files with the same filename (subject) that are stored in the >>> spam folder (spamlog), if UseSubjectsAsMaillogNames is selected. Default >>> is 0. A low value reduces the number of possibly duplicate mails, >>> assuming >>> that mails with the same subject will have the same content. A value of 0 >>> disables this feature. If this number of files with the same filename is >>> reached, new files will be stored in the discarded folder, which has to >>> be >>> defined for this feature to work.', >>> >>> >>> 'MaxKeepDeleted','Max Days of Keep Deleted', 'The maximum number in days >>> deleted files in the bayesian collection folders ( spamlog , notspamlog ) >>> will be kept. This is necessary when EmailBlockReport is used to handle >>> the file and the file is meanwhile deleted. The list of files that are >>> maked for deletion is stored in trashlist.db .' >>> >>> Delete files will no more get a filedate in future! >>> Files there filedate is expired, will be deleted by the rebuild task >>> before the rebuild of the spamdb is done. >>> >>> Thomas >>> >>> >>> DISCLAIMER: >>> ******************************************************* >>> This email and any files transmitted with it may be confidential, legally >>> privileged and protected in law and are intended solely for the use of >>> the >>> >>> individual to whom it is addressed. >>> This email was multiple times scanned for viruses. There should be no >>> known virus in this email! >>> ******************************************************* >>> >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and stay >>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>> http://p.sf.net/sfu/devconference >>> _______________________________________________ >>> Assp-test mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/assp-test >>> >> >> > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
