View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005278 | unreal | ircd | public | 2019-05-16 21:09 | 2024-09-09 16:55 |
| Reporter | PeGaSuS | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | assigned | Resolution | fixed | ||
| Platform | Unix | OS | Ubuntu | OS Version | 18.04 LTS |
| Product Version | 4.2.3 | ||||
| Fixed in Version | 6.1.8 | ||||
| Summary | 0005278: Add extban to ban users banned in another channel | ||||
| Description | We currently have the extban to ban users that are in a channel, with "+b ~c:#channelname". Would be nice if we could have an extban to ban users banned in another channel (so we can keep some kind of banlist sync across channels registered by the same person. I was thinking in something like "+b ~b:#channelname" or "+b ~C:#channelname". The latter goes in hand with the extban "~c" as they're kinda related. Thoughts? | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Yeah, I like it. Only (natural) caveat would be to do this only 1 level, so if the target channel has a ~c as well it should not be processed. Otherwise it becomes too costly in terms of CPU. |
|
|
This is now done. Mostly in ee1d6818b403a2d8719076e9700e93763abda0fb and 3c1ef65a0021afa79f33d29c2f1dc862dbb0f9e0 commit ee1d6818b403a2d8719076e9700e93763abda0fb Author: Bram Matthys <[email protected]> Date: Sat Sep 7 20:52:01 2024 +0200 Add +b/+e/+I ~inherit:#channel to inherit channel bans from another channel Several notes: * This only checks on-JOIN (not on nick change, message, etc) for performance reasons * If the #channel in ~inherit:#channel also contains ~inherit entries then those are not processed (no recursion and no looping) * Only a limited number of ~inherit entries is permitted. This will be moved to set:: items in a future commit so you can set different amounts for +b/+e/+I ~inherit. * This is work in progress, UnrealIRCd or the entire world could explode * Documentation will follow later Developers: * Sadly, clean_ban_mask() needed to be changed to have two more parameters, 'ban_type' and 'channel' were added at different positions. This because the module needs the ban type (EXBTYPE_BAN, EXBTYPE_EXCEPT, EXBTYPE_INVEX) and channel because it rejects based on number of existing ~inherit entries in the channel... and while is_ok() is called for local clients and has all this information, for services clients is_ok() is not called so the only way to reject the +beI is through xxx_conv_param() which comes from clean_ban_mask(). [..] commit 3c1ef65a0021afa79f33d29c2f1dc862dbb0f9e0 Author: Bram Matthys <[email protected]> Date: Sun Sep 8 17:15:26 2024 +0200 Add set::max-inherit-extended-bans to configure limits for ~inherit extban: Looks like this, with the current defaults: set { max-inherit-extended-bans { ban 1; ban-exception 1; invite-exception 1; } } |
|
|
It seems the +e/+I inherit runs is_banned() instead of checking +e or +I lists.. that's a bug. I may not have time to fix this in the next couple of days, so might be later. Also, +b ~inherit checks both +b _and_ +e on the target channel. I think that's how users would expect it ("if you are banned there you are banned here") but it kinda makes the +e ~inherit functionality redundant..... well... not really redundant since you could still opt-in to _only_ the +e ~inherit:#chan stuff and not the +b, but... not sure if that is very useful. For +I everything is as expected/fine. Reopening this bug until I fix at least the first issue :) |
|
|
Fixed +I but not the rest. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-05-16 21:09 | PeGaSuS | New Issue | |
| 2020-05-17 19:01 | syzop | Assigned To | => syzop |
| 2020-05-17 19:01 | syzop | Status | new => acknowledged |
| 2020-05-17 19:01 | syzop | Note Added: 0021581 | |
| 2024-09-08 18:54 | syzop | Status | acknowledged => resolved |
| 2024-09-08 18:54 | syzop | Resolution | open => fixed |
| 2024-09-08 18:54 | syzop | Fixed in Version | => 6.1.8 |
| 2024-09-08 18:54 | syzop | Note Added: 0023332 | |
| 2024-09-09 16:05 | syzop | Status | resolved => assigned |
| 2024-09-09 16:05 | syzop | Note Added: 0023336 | |
| 2024-09-09 16:55 | syzop | Note Added: 0023337 |
