View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002285 | unreal | ircd | public | 2005-01-16 08:25 | 2007-04-27 04:56 |
| Reporter | Rocko | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.3 | ||||
| Summary | 0002285: Define expiry-time for /spamfilter entrys | ||||
| Description | F u gline 0 1 86400 Reason [email protected] .+!.+@.+:.+ The expiry is 0 (permanent), the 1 one how long this spamfilter is added, and it would be great to add (now) a possibility to define the expire time for a spamfilter entry. Would be usefull especially for the "/spamfilter u", because removing them manually is many work and not that easy, because you must match the exactly /spamfilter command, and they won't expire until the whole networks gots down and no syncing was possible anymore. I don't know if it's possible to add this, or maybe make it optional like glines, and if no value is given, the default one (perm or the value from "[ default-bantime 1d;] in set block" should be taken. Old: Use: /spamfilter [add|del|remove|+|-] [type] [action] [tkltime] [reason] [regex] New: Use: /spamfilter [add|del|remove|+|-] [type] [action] [expiry-time] [tkltime] [reason] [regex] | ||||
| 3rd party modules | |||||
|
|
ive just finshed an mirc addon that runs the spamfilters into a mirc window and on right click removes the selected filter, nice n easy ;) (maybe i should take a new topic for this(?)) also an " edit " feature - allowing the change of only action and tkltime on a set filter |
|
|
The only problem with your propsed syntax, however, is that you have to disambiguate somehow the spamfilter expiry from the tkl expiry, unless you want to make the spamf expiry required. I guess this could be supereasy, but, consider this: /spamfilter add u gline 300 600 stupid realname here There's two ways this can be interpreted: with spamfilter expiry being 300 (seconds), tkltime being 600 (seconds I think), reason being "stupid" and regex being "realname here" (natually only realnames can have spaces, so you don't need the seperators :P), or with tkltime being 300 and reason being "600" and regex being "stupid realname here"), so there's ambiguity. Now I suppose you can just have a fixed rule that if there's two numbers then it's spamf expiry and tkl expiry. However, I think I have an idea that not only removes the ambiguity, but also places the spamf expiry parameter somewhere that makes more sense :) /spamfilter add u 300 gline 600 stupid realname here It makes more sense to put the spamfilter expiry parameter before the action (or maybe even before the type?) because then you can't be confused on if it's tkl expiry or spamfilter expiry. You wouldn't even know you're going to use tkls until you see "gline" as the action, so it must be a spamfilter expiry. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-01-16 08:25 | Rocko | New Issue | |
| 2005-01-16 18:10 | White_Magic | Note Added: 0008823 | |
| 2005-01-16 22:45 | aquanight | Note Added: 0008824 | |
| 2007-04-27 04:56 |
|
Status | new => closed |
| 2007-04-27 04:56 |
|
Resolution | open => no change required |
