View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002908 | unreal | module api | public | 2006-05-10 05:25 | 2006-11-12 15:20 |
| Reporter | dotslasher | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.5 | ||||
| Summary | 0002908: chanfilter module | ||||
| Description | This module provides the channel mode +g (not to be confused with +G) which allows channel operators to choose which words to filter from their channel In config file: <chanfilter maxsize="32"> * Channel mode +g: This channel takes one parameter in the same way as modes +b and +o. You must specify a word to block as the parameter, and if any user (including ops) types the word on channel, the server will filter out their line, sending them the following message: #channel Your message contained a censored word, and was blocked As with all 'list' type modes, you may list the items which are set by using the mode with no parameters as follows: MODE #channel +g or MODE #channel g this is taken from inspircd. I think its a very useful feature so that the channel operators can choose which words they want to block, and not the ones in the config file. One small difference from the inspircd module: would it be possible to have wildcards accepted? example /mode #chan +g test --> this would block test only. but if you do /mode #chan +g *test* this would also block 'testing' 'tester' getest' etc. | ||||
| 3rd party modules | |||||
|
|
While not implemented exactly the same way as you asked for, there is a module which does this via extbans: http://www.unrealircd.com/index.php?page=modules&mod=module&id=87 |
|
|
tnx Syzop |
|
|
well there a module for channel mode +j and that was implented, i think the ~T should be added to the core now as an extended ban, it looks very usful and even perhaps it can go futher than just " block " (maybe kick and kick ban?) since it would be part of the ircd |
|
|
Why should this be part of the core when it is a module? |
|
|
the same reason +j was added to the core but was a module :) |
|
|
I'm waiting for a reason... +j was added to core because the modules system is too deficient to do things efficiently. Same reason SSL won't make it into a module. (no way of associating arbitrary data with a user, channel, server for starters). *edit* forgot my last sentance... This module isn't affected quite so badly as it's a simple one way link. +j needed to be associated with user and channel data. (Though I maintain it'd be easier to fix the core problem rather than keep jamming stuff in, but oh well.) |
|
|
Fine as a module for now. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-05-10 05:25 | dotslasher | New Issue | |
| 2006-05-10 05:51 | syzop | Note Added: 0011686 | |
| 2006-05-10 06:57 | dotslasher | Note Added: 0011689 | |
| 2006-05-16 10:47 | White_Magic | Note Added: 0011707 | |
| 2006-05-17 01:03 | w00t | Note Added: 0011712 | |
| 2006-05-17 03:45 | White_Magic | Note Added: 0011715 | |
| 2006-05-21 00:30 | w00t | Note Added: 0011745 | |
| 2006-05-21 00:31 | w00t | Note Edited: 0011745 | |
| 2006-11-12 15:20 | syzop | Status | new => closed |
| 2006-11-12 15:20 | syzop | Note Added: 0012652 | |
| 2006-11-12 15:20 | syzop | Resolution | open => no change required |
| 2017-01-06 15:48 | syzop | Category | module => module api |
