View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002095 | unreal | ircd | public | 2004-09-26 04:45 | 2012-12-26 19:49 |
| Reporter | Stealth | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.4-alpha1 | ||||
| Summary | 0002095: remove helpop noticing stuff (was: /helpop filtering suggestion) | ||||
| Description | keep /helpop as an online help system, but remove the forwarding-to-helpops stuff. possibly keep umode +h for now though, until we've debated about that, since that goes further than the forwarding-of-helpopmsgs thingy == old report was (just for reference): == The ability to badword or spamfilter /helpop's would be a good idea. The reason is: /helpop is an uncommon vulnerability for flooders to take advantage of, since it forwards anything not matched by a help block to all HelpOps. Since all opers are set to +h by default, they receive the flood in server-notice form. Being able to badword/spamfilter /helpop's would give server admins the ability to protect their servers from such a flood by using regexp's to detect and block repeated text on the same line. Because floods are repeated, this would be extremely effective against these floods. A badword type will also be a good idea to block helpop's from users who do not wish to use the nicest language in their helpop. SpamFilter can be used to block the floods, and badword can be to censor foul language. The types for each can be "help" or "helpop". | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| has duplicate | 0002305 | closed | Spamfilter + helpop <-> helpop allow (?) |
|
|
This sounds like a great idea. |
|
|
From my recollections in the support chan... codemastr wants to remove the send-to-all-+h aspect of /helpop entirely... |
|
|
This is a crazy idea! SomeUser types: /helpop F*ck sh*t f*ck ... SomeOper types: /kill SomeUser Stop that Problem solved. This feature is not going to be implemented. You want us to waste 8 bytes of memory per user, plus a list of badwords for a flood that might occur once every 20 years? I'm not about to do that. If you want this, you're going to have to find someone who will make a module. As aquanight said, I'd much rather just remove the whole /helpop going-to-+h thing. No one uses it anyway. |
|
|
Even better.. remove it.. though some people do actually use /helpop .... |
|
|
I know one instance, on a net I frequent... I had a channel that (since anope wouldn't let me mlock +M :( ) I had +m and SECURE ON and AUTOVOICE 0. One time, a user came in (while I was away), and there was one other person (who was an ircop/helpop). The user that came in wasn't registered, so supposedly he used /helpop to communicate :P . But, other than that... I can't really understand what it was for... |
|
|
My own network is quite small, and it seems pointless to have someone in #Help all the time. I have the topic locked so if someone needs help, all they need to do is type /helpop helpme, and that will send a message to all my opers. |
|
|
Filtering spam from HelpOps is overkill... |
|
|
I think /helpop should not forwarding anything to helpoperators at all. Leave it only to explain the commands. Something like a manual. |
|
|
I've been annoyed with HelpOps as well. Some smart-aleck mIRC scripter on my network figured out how to make his mIRC send a /helpop nag message everytime one of the following numerics was returned: * Youre on too many channels * Youre banned (from our help room) * Nickname change error etc... list goes on. Everytime one of those numerics was sent to his mIRC, his script sent a /helpop telling us of the condition example (*** Helpop from Someuser: 405 Reply (add more channels!)) Of course, setting -h or scripting an ignore function for his nick was a simple task, but if the /helpop communications was disabled that would be better. I propose a replacement for /helpop messaging: A function to find all users set +h, and list their away status: /newcommand HelpOp: Zell on [Server], is available for help HelpOp: User2 on [Server], is a HelpOp, but is currently Away Could easily be made into a module, but if the HelpOp communications is removed, that would be a good feature to include into the ircd. |
|
|
... /helpop ignore nick!user@host :P Haven't found the unignore yet so you'd probably have to restart for that to work, and I think that only applies locally. |
|
|
I've posted a poll on SOMEURLTHATGETSBROKENBYMANTIS about removing this "/helpop <some question here>" feature. ok.. why are urls fucked up ? www.phpmemx.net/~unrealir/forums/viewtopic.php?t=1410 |
|
|
(Probably doesn't like the ? character in URLS :/ ) |
|
|
URL worked fine when I clicked it in my email :-P Heh, am I the only loser who opts in to get email replies? |
|
|
I like this feature. I've found it useful to help people quite a few times. Of course, I hang on smaller networks where everyone knows everyone mostly. Isn't +h a flag people can configure in unrealircd.conf anyway? Hence the whole "Help operator" concept? If you don't want to help people, don't set it. |
|
|
Here's my preferred scenario: If someone needs help and can't find it in /helpop ?command/topic, they should /join #help (almost anyone can teach them the /join command first). If your help channel has a different name, add a deny channel block to forward users from #help to #whatever. If you want to help people, join the help channel. If someone floods the help channel, channel modes to the rescue!! :D The only times I receive HelpOps are when someone: - typos - doesn't listen to what I just told them - or is being a problem |
|
|
you know what, i cant even read all the replies but i say this 1) helpop is pointless. 2) if a user needs an ircop, they can join an official help channel or ircop channel. if they need other support, it should be in that networks motd or website. It shouldnt be up the IRCd to make these networks easier to run, ffs these lazy admins dont take preventive steps in making their own network their own. get rid of this stupid helpop feature kthx |
|
|
i agree with almost everyone from above: remove the sending-to-helpops etc stuff. you can use aliases if you'd want something similar, but just mentioning #help and such is a better idea. so I think this bugreport should be renamed (or whateve) to removing helpop sending to +h. |
|
|
Woops, forgot to say I fixed this in .2380 |
|
|
http://hg.unrealircd.org/hg/unreal/rev/c1fb5287c62d HelpOp usermode is kept around for vanity purposes for now. We'll decide that later. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-09-26 04:45 | Stealth | New Issue | |
| 2004-09-26 04:51 | Valkyrie | Note Added: 0007792 | |
| 2004-09-26 05:29 | aquanight | Note Added: 0007793 | |
| 2004-09-26 15:59 |
|
Note Added: 0007795 | |
| 2004-09-26 20:21 | Valkyrie | Note Added: 0007804 | |
| 2004-09-27 06:28 | aquanight | Note Added: 0007805 | |
| 2004-09-27 06:52 | Stealth | Note Added: 0007807 | |
| 2004-10-01 03:47 | al5001 | Note Added: 0007838 | |
| 2004-10-03 10:35 | vonitsanet | Note Added: 0007860 | |
| 2004-11-02 11:32 | Zell | Note Added: 0008216 | |
| 2004-11-02 12:32 | aquanight | Note Added: 0008221 | |
| 2005-01-25 18:48 | syzop | Relationship added | has duplicate 0002305 |
| 2005-01-25 19:06 | syzop | Note Added: 0008922 | |
| 2005-01-25 19:07 | syzop | Note Edited: 0008922 | |
| 2005-01-26 00:41 | aquanight | Note Added: 0008925 | |
| 2005-01-26 15:54 | Zell | Note Added: 0008929 | |
| 2007-04-18 18:42 | WolfSage | Note Added: 0013550 | |
| 2007-04-19 02:30 |
|
Status | new => acknowledged |
| 2007-04-25 16:43 | Shining Phoenix | Note Added: 0013701 | |
| 2007-04-26 03:01 | Bricker | Note Added: 0013718 | |
| 2007-04-26 04:33 | syzop | Note Added: 0013719 | |
| 2007-04-26 05:46 | syzop | Summary | /helpop filtering suggestion => remove helpop noticing stuff (was: /helpop filtering suggestion) |
| 2007-04-26 05:46 | syzop | Description Updated | |
| 2007-05-04 08:38 |
|
Status | acknowledged => resolved |
| 2007-05-04 08:38 |
|
Fixed in Version | => 3.3-alpha0 |
| 2007-05-04 08:38 |
|
Resolution | open => fixed |
| 2007-05-04 08:38 |
|
Assigned To | => stskeeps |
| 2007-05-04 08:38 |
|
Note Added: 0013999 | |
| 2011-07-19 14:19 | syzop | Assigned To | stskeeps => |
| 2011-07-19 14:19 | syzop | Status | resolved => needs re porting |
| 2012-12-26 19:48 |
|
Note Added: 0017281 | |
| 2012-12-26 19:48 |
|
Status | needs re porting => resolved |
| 2012-12-26 19:48 |
|
Fixed in Version | 3.3-alpha0 => 3.4-alpha1 |
| 2012-12-26 19:48 |
|
Assigned To | => nenolod |
