0003276: Max bantime - UnrealIRCd Bug Tracker

(0013971)
WolfSage (reporter)
2007-05-01 19:51

This should handle what you're looking for fine. There's the slight issue of it over-riding default-bantime if default-bantime > max_bantime. It makes sense, but a warning or an error should probably be thrown to the user.

Testing and suggestions would be appreciated.

(0014051)
syzop (administrator)
2007-05-08 13:41

looks ok? :) (viewed patch only)

(0014052)
syzop (administrator)
2007-05-08 13:44

But yeah, a warning would be nice I think... hmmm good pro/con's for both actually (annoying & "yes I know by now" vs "wtf I said perm"), etc... but if we risk any confusion (which we do) always go with the warning IMHO... ;)
(though it should probably be more of a NOTE: rather than WARNING:)

(0014117)
Stealth (administrator)
2007-05-13 12:03

Spamfilter can override this, perhaps it should check when the spamfilter is set

If default-bantime > max-bantime, it chould conf fail

A notice to the oper setting the ban would be nice, and let the oper know it has been set as max-bantime

I was unable to test U:Lines, but everything else looks fine

(0014132)
Stealth (administrator)
2007-05-14 00:17

Another small note: Perhaps we should also apply this to shuns, since that is a type of ban

(0014133)
stskeeps (reporter)
2007-05-14 04:41

Suitable for merging i guess?

(0014135)
WolfSage (reporter)
2007-05-14 08:15

Hmm, good points. This should apply to spamfilter as well. I'll add this and default ban checking to spamfilters, and a warning if the values are different, (I don't really think it's worth failing over), and then it should be good to go.

(0014136)
Bricker (reporter)
2007-05-14 09:43

i thought unreal was planning of getting rid of shun? it should, its abusive

(0014189)
stskeeps (reporter)
2007-05-20 03:55

shun is a fine and good tool.

(0014192)
Shining Phoenix (reporter)
2007-05-20 04:03

Using shun on an annoying person is very satisfying. That should be enough reason to keep it =P

(0015895)
Stealth (administrator)
2009-07-24 00:50

Updated for possible addition to 3.2.9. Patch is attached, but needs a little more work. (see above)

Issue History
Date Modified	Username	Field	Change
2007-04-17 19:03	Stealth	New Issue
2007-04-18 04:49	stskeeps	Status	new => acknowledged
2007-04-18 04:49	stskeeps	Relationship added	child of 0003049
2007-05-01 19:49	WolfSage	File Added: max_bantime.patch
2007-05-01 19:51	WolfSage	Note Added: 0013971
2007-05-08 13:41	syzop	Note Added: 0014051
2007-05-08 13:44	syzop	Note Added: 0014052
2007-05-13 12:03	Stealth	Note Added: 0014117
2007-05-13 19:06	tabrisnet	Issue Monitored: tabrisnet
2007-05-14 00:17	Stealth	Note Added: 0014132
2007-05-14 04:41	stskeeps	Note Added: 0014133
2007-05-14 04:41	stskeeps	Status	acknowledged => confirmed
2007-05-14 08:15	WolfSage	Note Added: 0014135
2007-05-14 09:43	Bricker	Note Added: 0014136
2007-05-19 22:07	WolfSage	Status	confirmed => assigned
2007-05-19 22:07	WolfSage	Assigned To	=> WolfSage
2007-05-20 03:55	stskeeps	Note Added: 0014189
2007-05-20 04:03	Shining Phoenix	Note Added: 0014192
2009-07-24 00:50	Stealth	QA	=> Not touched yet by developer
2009-07-24 00:50	Stealth	U4: Need for upstream patch	=> No need for upstream InspIRCd patch
2009-07-24 00:50	Stealth	U4: Upstream notification of bug	=> Not decided
2009-07-24 00:50	Stealth	U4: Contributor working on this	=> None
2009-07-24 00:50	Stealth	Note Added: 0015895
2009-07-24 00:50	Stealth	Assigned To	WolfSage =>
2009-07-24 00:50	Stealth	Status	assigned => acknowledged
2009-07-24 00:50	Stealth	version	3.3-alpha0 => 3.2.9

Notes
(0013971) WolfSage (reporter) 2007-05-01 19:51	This should handle what you're looking for fine. There's the slight issue of it over-riding default-bantime if default-bantime > max_bantime. It makes sense, but a warning or an error should probably be thrown to the user. Testing and suggestions would be appreciated.

(0014051) syzop (administrator) 2007-05-08 13:41	looks ok? :) (viewed patch only)

(0014052) syzop (administrator) 2007-05-08 13:44	But yeah, a warning would be nice I think... hmmm good pro/con's for both actually (annoying & "yes I know by now" vs "wtf I said perm"), etc... but if we risk any confusion (which we do) always go with the warning IMHO... ;) (though it should probably be more of a NOTE: rather than WARNING:)

(0014117) Stealth (administrator) 2007-05-13 12:03	Spamfilter can override this, perhaps it should check when the spamfilter is set If default-bantime > max-bantime, it chould conf fail A notice to the oper setting the ban would be nice, and let the oper know it has been set as max-bantime I was unable to test U:Lines, but everything else looks fine

(0014132) Stealth (administrator) 2007-05-14 00:17	Another small note: Perhaps we should also apply this to shuns, since that is a type of ban

(0014133) stskeeps (reporter) 2007-05-14 04:41	Suitable for merging i guess?

(0014135) WolfSage (reporter) 2007-05-14 08:15	Hmm, good points. This should apply to spamfilter as well. I'll add this and default ban checking to spamfilters, and a warning if the values are different, (I don't really think it's worth failing over), and then it should be good to go.

(0014136) Bricker (reporter) 2007-05-14 09:43	i thought unreal was planning of getting rid of shun? it should, its abusive

(0014189) stskeeps (reporter) 2007-05-20 03:55	shun is a fine and good tool.

(0014192) Shining Phoenix (reporter) 2007-05-20 04:03	Using shun on an annoying person is very satisfying. That should be enough reason to keep it =P

(0015895) Stealth (administrator) 2009-07-24 00:50	Updated for possible addition to 3.2.9. Patch is attached, but needs a little more work. (see above)