View Issue Details

IDProjectCategoryView StatusLast Update
0002222unrealircdpublic2005-01-23 13:41
ReporterSnakeAssigned Tocodemastr 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.2.2 
Target VersionFixed in Version3.2.3 
Summary0002222: SVSMODE -b|e does not work with new extended bans.
DescriptionWell, some IRC Services use the command SVSMODE #channel -b nick or SVS2MODE #channel -b nick to delete all bans which are touching the given nick. The problem is: SVSMODE -b / SVS2MODE -b commands do not work with extended bans (it will never delete extended bans if a nick is specified).

The same problem appears with SVSMODE -e / SVS2MODE -e commands.
TagsNo tags attached.
3rd party modules

Activities

syzop

2004-12-05 11:42

administrator   ~0008504

I'm not really sure if it should?
Like if there's a ban ~c:#blah, should it be removed if user X is in #blah and you request all bans to be removed for user X? Debatable...
And stuff like ~q/~n are not 'real bans', they might even be 'policy bans' like +b ~n:*!*@*.aol.com... I'm not sure if you want those suddenly removed then (actually I would think 'no').
Removing matching ~q extbans sounds logical however, since that's a "real ban".

White_Magic

2004-12-05 12:46

reporter   ~0008507

i believe they shouldnt be able to touch any bans what so ever, kinda unresonable but its the same with clients and mirc, mirc doesnt detect an extended ban, i took time to make my own mirc detect a valid extended ban which effects me/ my channels im in/ my realname, i see it as agood thing, it helps stop channel take overs,

codemastr

2004-12-05 13:22

reporter   ~0008510

Yeah, actually, I considered this about a week ago. I could not think of how exactly you could make it deal with extended bans. As syzop said, many extended bans are for "policies" not to stop one user. Meaning a +b ~c:*warez* isn't meant to keep JoeUser out, it is meant to stop warez people from coming in. So most likely, you don't want that ban removed.

Snake

2005-01-09 10:47

reporter   ~0008747

mhh.. ok for extended bans, this point of view is debatable...

Other problem: I have seen today that SVSMODE -b does not unban bans placed on a IP mask. However, if you place a ban on the IP of an user, the user is not able to join the channel, so this ban works and it's a real ban :) SVSMODE -b should be able to remove bans on a IP address I think (it works with real hosts, so why not with IP address ?).

syzop

2005-01-09 15:33

administrator   ~0008748

Last edited: 2005-01-09 15:34

> it works with real hosts, so why not with IP address ?

No special reason whatsoever, it's just that neither codemastr nor me added that functionality (yet). Opened a new bugreport about it: 0002270

*edit* typo in bugid */edit*

codemastr

2005-01-22 14:06

reporter   ~0008893

Last edited: 2005-01-22 14:08

Syzop, I've reached a conclusion that this should *not* be done (for reasons we mentioned). But, I was thinking, perhaps there should be a svsmode_remove callback for the extbans? The reason is, for some extbans, it might make sense. For example I mentioned I created a ~t which works just like +b except the bans are removed after N minutes. So it would make sense for svsmode -b to remove a ~t ban. So maybe extban developers should have that option? Afaik, adding another callback wouldn't really break anything since bzero is called on the struct beforehand.

*edit: actually, we don't even really need a callback, just a flag.

syzop

2005-01-22 14:19

administrator   ~0008894

Yup, sounds good (*love structs ;p*)
Also I guess we could set that flag for ~r too?
[I made a mistake in my last sentence of my first reaction dated 2004-12-05.. corrected sentence: 'Removing matching ~r extbans sounds logical however, since that's a "real ban"'.]
Unless you would call that a policy ban, but.. hm ;P

codemastr

2005-01-22 15:52

reporter   ~0008895

Last edited: 2005-01-22 15:52

I've never been quite sure what ~r is. It can be policy or a real ban. ~r:*fuck* is a policy ban. But ~r:*Some_guy_who_uses_the_same_realname* isn't...

*edit: Then again though, +b *fuck*!*@* is probably a policy ban too.

aquanight

2005-01-23 12:04

reporter   ~0008897

Well, services can handle the policy bans...

/chanserv AKICK #channel ADD ~r:*whatever*
/chanserv AKICK #channel STICK ~r:*whatever*

Since IIRC SVSMODE -b sends back the list of removed bans so services can just re-add the stickied ones.

codemastr

2005-01-23 13:41

reporter   ~0008900

There is now an option, EXTBOPT_CHSVSMODE that will allow module coders to determine whether or not the extban should be affected by SVSMODE -b/-e. The only builtin one that is is ~r. The others will remain. This is added in .236

Issue History

Date Modified Username Field Change
2004-12-05 06:27 Snake New Issue
2004-12-05 11:42 syzop Note Added: 0008504
2004-12-05 12:46 White_Magic Note Added: 0008507
2004-12-05 13:22 codemastr Note Added: 0008510
2005-01-09 10:47 Snake Note Added: 0008747
2005-01-09 15:33 syzop Note Added: 0008748
2005-01-09 15:34 syzop Note Edited: 0008748
2005-01-22 14:06 codemastr Note Added: 0008893
2005-01-22 14:08 codemastr Note Edited: 0008893
2005-01-22 14:19 syzop Note Added: 0008894
2005-01-22 15:52 codemastr Note Added: 0008895
2005-01-22 15:52 codemastr Note Edited: 0008895
2005-01-23 12:04 aquanight Note Added: 0008897
2005-01-23 13:41 codemastr Status new => resolved
2005-01-23 13:41 codemastr Fixed in Version => 3.2.3
2005-01-23 13:41 codemastr Resolution open => fixed
2005-01-23 13:41 codemastr Assigned To => codemastr
2005-01-23 13:41 codemastr Note Added: 0008900