View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002222 | unreal | ircd | public | 2004-12-05 06:27 | 2005-01-23 13:41 |
| Reporter | Snake | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.2.2 | ||||
| Fixed in Version | 3.2.3 | ||||
| Summary | 0002222: SVSMODE -b|e does not work with new extended bans. | ||||
| Description | Well, 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. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
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". |
|
|
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, |
|
|
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. |
|
|
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 ?). |
|
|
> 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* |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
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. |
|
|
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 |
| 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 |
|
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 |
|
Note Added: 0008893 | |
| 2005-01-22 14:08 |
|
Note Edited: 0008893 | |
| 2005-01-22 14:19 | syzop | Note Added: 0008894 | |
| 2005-01-22 15:52 |
|
Note Added: 0008895 | |
| 2005-01-22 15:52 |
|
Note Edited: 0008895 | |
| 2005-01-23 12:04 | aquanight | Note Added: 0008897 | |
| 2005-01-23 13:41 |
|
Status | new => resolved |
| 2005-01-23 13:41 |
|
Fixed in Version | => 3.2.3 |
| 2005-01-23 13:41 |
|
Resolution | open => fixed |
| 2005-01-23 13:41 |
|
Assigned To | => codemastr |
| 2005-01-23 13:41 |
|
Note Added: 0008900 |
