View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005070 | unreal | ircd | public | 2018-02-11 20:29 | 2019-02-06 12:26 |
| Reporter | Gottem | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 4.0.17 | ||||
| Fixed in Version | 4.2.2-rc1 | ||||
| Summary | 0005070: Multiple channels/targets in KICK doesn't work properly | ||||
| Description | It seems that multikick is restricted to servers/U:Lines to begin with, so chanops/etc can't use it regardless of what I'm describing below. At first I thought maybe my client was screwing up the /kick command, so I tried "/raw KICK #chan1,#chan2 nick1,nick2 :test" too but it still only kicks nick1 from #chan1. When I use a leaf simulator thing to send "KICK #chan1,#chan2 nick1,nick2 :test", Unreal only kicks both nicks from #chan1. I'm fairly certain it stops after the first channel (at least for servers/etc) because of this: for (; (name = strtoken(&p, parv[1], ",")); parv[1] = NULL) chptr = get_channel(sptr, name, !CREATE); {snip} for (; (user = strtoken(&p2, parv[2], ",")); parv[2] = NULL) While processing users for #chan1 parv[2] is set to NULL so everything falls upon the p2 buffer. But, as soon as all users are parsed once p2 is now empty. Then when the outer loop gets to #chan2, there are no users left to parse and nothing happens. =] | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | N/A, tested without any | ||||
|
|
This seems to come up every now and then - see 0003258 0002394 0003474 0001082 Basically it is or was a decision to keep it at 1. |
|
|
I should add that nowadays there's a proper way to communicate the limit/availability of this to clients, through TARGMAX= in 005. |
|
|
I did come across those but since they were about the 3.x branch, I figured it may have changed with 4.x so I reinvestigated it. :> But if I understand you correctly, the limit of _channels_ in a /kick command is always 1, but for _nicks_ it's TARGMAX (think it's actually called MAXTARGETS tho :D)? This in reference to my opening sentence in the OP, since chanops are limited to 1 regardless while servers/U:Lines can kick multiple people at once. You did mention that in 0001082 but perhaps it could be changed to allow chanops to do it too (or a configurable for minimum access required). I don't see a multi-channel/multi-nick kick being used much, but multi-nick/single-channel might be useful so the above paragraph would be a nice compromise. =] |
|
|
+1 for the single channel but multi user. that would help to ban a few spam bots that usually shares the same host after setting the +b in the host. |
|
|
Fine be me to implement something to allow kicking multiple users in one channel (and as said, communicate through TARGMAX) Not a "must be in 4.0.19", though. |
|
|
You can now kick 4 people in 1 command. commit 1e1f750b443c802b4ef10a774c6fa3d61bfdbc1e Author: Bram Matthys <[email protected]> Date: Mon Feb 4 17:51:09 2019 +0100 New set::max-targets-per-command which configures the maximum number of targets accepted for a command, eg /MSG nick1,nick2,nick3,nick4 hi. Also changed the following defaults (previously hardcoded): * PRIVMSG from 20 to 4 targets, to counter /amsg spam * NOTICE from 20 to 1 target, to counter /anotice spam * KICK from 1 to 4 targets, to make it easier for channel operators to quickly kick a large amount of spambots See https://www.unrealircd.org/docs/Set_block#set::max-targets-per-command |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-02-11 20:29 | Gottem | New Issue | |
| 2018-03-25 14:15 | syzop | Note Added: 0020072 | |
| 2018-03-25 14:18 | syzop | Note Edited: 0020072 | |
| 2018-03-25 14:19 | syzop | Note Added: 0020073 | |
| 2018-03-29 17:21 | Gottem | Note Added: 0020077 | |
| 2018-06-21 09:39 | PeGaSuS | Note Added: 0020176 | |
| 2018-07-14 16:43 | syzop | Assigned To | => syzop |
| 2018-07-14 16:43 | syzop | Status | new => acknowledged |
| 2018-07-14 16:43 | syzop | Note Added: 0020201 | |
| 2019-02-06 12:26 | syzop | Status | acknowledged => resolved |
| 2019-02-06 12:26 | syzop | Resolution | open => fixed |
| 2019-02-06 12:26 | syzop | Fixed in Version | => 4.2.2-rc1 |
| 2019-02-06 12:26 | syzop | Note Added: 0020482 |
