View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005531 | unreal | ircd | public | 2020-01-14 09:49 | 2020-11-27 17:24 |
| Reporter | PeGaSuS | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | acknowledged | Resolution | open | ||
| Platform | Unix | OS | Ubuntu | OS Version | 18.04 LTS |
| Product Version | 5.0.1 | ||||
| Summary | 0005531: Option to deny/allow channels on the fly | ||||
| Description | This all started because of this: <@Jobe> ammusingly enough in ircu you can gline channel names Which gave me the following idea: Since we have "deny channel" block would be nice to have some kind of option to do the same in the spamfilter. My thoughts were to have something like this: /SPMAFILTER add -simple C redirect #helpop The_official_help_channel_is_#help #help In the above command, we have a new type: C for channel name, a redirect option and the target channel. Other actions such as block, tempshun should work as they work until now. I also thought in having a specific command like: /DENYCHAN #channel #redirect_channel/- reason On this command, the second parameter is the #channel to be redirect to or none if "-" is given. I assume that we would need the counterpart somehow (the allow channel option) to be implemented also. My idea for spamfilter is: /SPAMFILTER add -simple C allow - Official_help_channel #help As for a separated command: /ALLOWCHAN #channel - reason (I've kept the "-" since we would be using this syntax in the denychan command) I'm just requesting this, as this would be a handy way to allow admins to allow/deny channels on the fly without the need to edit config files and therefore speed up the way admins would be able to deny a channel reported as a warez channel or something like that. Cheers | ||||
| Additional Information | ### Here's a snippet of the IRC discussion that made me open this feature request ### 12:52:36 <@Jobe> ammusingly enough in ircu you can gline channel names 12:52:45 <@Jobe> which stops people joining matching channels 12:54:14 <@Jobe> ofc if you want some real confusion in ircu then you should know that a gline can be set on a single server only, or globally 12:54:25 <@Jobe> for the former you can even set said gline on a remote server 12:54:53 <@Jobe> ofc the extra /gline param that makes all that happen confuses a lot of new ircu ircops 12:55:24 <@Jobe> cause if you dont include the extra param, then it sets a local only gline, (similar to unreals /kline) 12:55:35 <PeGaSuS> o.O 12:55:57 <PeGaSuS> then isn't a true G-Line 12:56:12 <PeGaSuS> G(lobal)-Line 12:56:15 <PeGaSuS> xD 12:59:19 <PeGaSuS> but actually you gave me an idea to make a feature request on the bug tracker xD 13:00:57 <PeGaSuS> but now I'm on the phone, so I'll make it later. 13:02:52 <PeGaSuS> basically is a new type in spamfilter to "disable" channels on the fly.. probably something like: /SPAMFILTER add -simple C block - This_channel_cannot_be_registered #channel 13:03:02 <PeGaSuS> or something along those lines :> 13:06:23 <@Jobe> basically a channel name type 13:06:43 <PeGaSuS> or a /denychan command that would work like https://www.unrealircd.org/docs/Configuration#Deny_channel_block 13:07:04 <@Jobe> think id prefer spamfilter tbh 13:07:06 <@Jobe> far more flexible 13:07:32 <PeGaSuS> like: /denychan #channel --reason reason --redirect #otherchannel 13:08:10 <PeGaSuS> would be a neat idea, right? having that kind of spamfilter/command? 13:08:21 <@Jobe> well 13:08:31 <@Jobe> dont think --reason and --redirect are needed 13:08:42 <@Jobe> channel names cant contain spaces 13:08:58 <@Jobe> so perhaps second param as redirect target, or "-" for none, and third onwards as reason 13:09:17 <@Jobe> also allowing a redirect to "0" :P 13:09:39 <PeGaSuS> oh.. so, /denychan #channel #other/- Channel can't be registered/used 13:10:07 <PeGaSuS> that could work 13:10:45 <PeGaSuS> I'll suggest both in the bug tracker. then if they decide to implement it, they can choose one or even both :) 13:10:52 <@Jobe> or even better 13:11:06 <@Jobe> seeing as the redirect channel needs to be a valid channel name 13:11:12 <@Jobe> it could just be an optional param 13:11:20 <@Jobe> if it starts with a #, then assume redirect target 13:11:22 <@Jobe> else assume reason 13:11:38 <PeGaSuS> great idea, Jobe 13:13:35 <PeGaSuS> on the spamfilter could be something like: /SPAMFILTER add -simple C redirect #channel reason_goes_here #blocked_channel 13:16:54 <PeGaSuS> older actions would work as the same. so if gline was specified as action, the users joining said channel would be G-Lined 13:18:30 <PeGaSuS> but in this case we'd have a new type (C, for channel name), a new action (redirect), and instead of time, a channel name to be redirected | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
