View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001247 | unreal | ircd | public | 2003-09-15 16:14 | 2004-02-05 01:35 |
| Reporter | auspice | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Summary | 0001247: Some suggestions... | ||||
| Description | UnrealIRCd is getting better and better, more and more professional. I Know It! here is some more feature to make it even more professional - Make IRCop can use /DCCDENY and /UNDCCDENY not only for admin (we don't want 100 admins for just working on dccdeny). - Again make /FJOIN to force user join a channel but not override mode (IRCop) and /SAMODE to force yourself join a channel and override any mode (+a). - Make, umode +h stay even if you dont'have umode +o but you can't +h yourself and it's loose when you -o. (our network need helpop that can listen to chatops message but not an IRCop) - Is SVS2MODE support nomask? I seem can't make it to work please add it if you can. - Umode +d tell any user who private you that you don't wish to recieve this message (IRCop may override it) it's +R like but it's apply to all non and registered users. - /kline /zline /gline /gzline /shun default expiry don't make it permanence, if expiry not given the expire time would be the default one. | ||||
| 3rd party modules | |||||
|
|
My opinions: Your requests are very network-specific, and I guess not much people would like every of your ideas. 1. I agree that at least Global IRCops should have that privilege, or it would be also fine if you can set a specific operflag for these commands. However DCCDENY stuff are rather for server admins, aren't they? 2. FJOIN is great for certain cases, but people might mention the abusive side of this command. If not, only Services Admins should have the privilege to use it. 3. +h shouldn't stay without +o or +O. Non-ircops should use a help channel instead. Or shall I tell you what HelpOp means? 4. I have a guess it's a known problem. Why should Services change snomasks on a user? My arguments are: +s is a local mode and snomasks are private settings. 5. Let's make a compare: if someone ignores you with the command /ignore (on client side), you'll never receive an automatic answer. The theory is the same theory with /silence. Btw, automatic replies are the best way to make flood. 6. I want permanent bans. Using only fe. /kline victim is fast and efficient. |
|
|
- should DCCDENY for Admin only? - with your opinions you are not trusting your IRCop work, then get them out from the oper list. - what is helpop? - than why you have umode +R? - if you add 2000 kline a day are you going to remove them? imagine you run a 2000+ users network. don't say no such network running UnrealIRCd, it's will or it is. |
|
|
Hmm.. There is already /sajoin, to force a user, to join a channel, and /sapart, to force a user to part a channel. That command is only for ServicesAdmins or higher, and thats good so. Then.. /samode is a mode, where you can set modes on a #channel, not to override any modes when joining. In earlier versions, you was able to join any channel and override all modes.. but that is removed and won't come back I think. And that part with the bans... I saw a bug/feature report, with the suggestion, to have a command like /gline -ALL or something. But that Idea with the default expiry is maybe not so bad. I had the problem too.. someone added glines very fast, because of a flood. Then we had xx glines in the list, which never will expire. Then I was removing one for one until I had removed them all. Much work ;) |
|
|
1. [DCCDENY] Dunnow... I agree with angrywolf that this is an admin task but maybe a flag could be added. 2. [FJOIN/SAMODE] huh?? 3. [don't loose umode +h on deoper] Nah. 4. [SVS2MODE+snomasks] No support for that atm, _maybe_ in the future. 5. [glines timeout etc] yes, this would be nice (well not for me, but some admins might like it) I might have a look at 5, it's a minor change and could be useful, but all the rest won't make it in (at least) beta18. |
|
|
auspice: 2. I agree with adding a command like FJOIN, since SAJOIN doesn't do the join on normal users when a ban or a channel mode restricts joins to oper only, admin only, etc. 3. I went into my own pitfall, well, I wanted to say being available for help is a task specially for ircops. 4. By the way, svs2mode+snomask might be useful for setting/removing snomasks on normal users (with a similar reason as your 3rd point). 5. No, I'm not an Unreal coder, and I don't have a clue. They were just my opinions... 6. With the reasons you and Rocko provided I agree. edited on: 09-16-03 05:06 |
|
|
oh if he means that with FJOIN, then it's the same as 0000518 except to make it a new command. |
|
|
SAJOIN right now is doing FJOIN work, the real meaning of SAJOIN is to join any channel even it banned, invite only... we don't have to use SAMODE to remove the mode, it's useful for admin who want to check out what going on in one channel that it's not belong to him/her but it's banned. |
|
|
You can invite yourself to override bans etc. |
|
|
ahh my idea was when u do /SAJOIN u also can't be kicked by any op too. Helpop is someone who available for help. anyway it's feature, have is better than have no and it's not harm to anything too. |
|
|
umode +q, no it will not be implemented/combined in/with SAJOIN or something. |
|
|
syzop forgot to post it here. default bantime is now added in the latest CVS Version ;) - Added set::default-bantime. It allows you to set the default time for a gline/kline/gzline/ shun/etc when the time is not not specified (like with /gline *@*.stupid.net). |
|
|
For the DCCDENY part, I think, only Server Admins and higher should be able to use that. This Bug Report remind me about dccallow.. I found this bug report http://bugs.unrealircd.org/bug_view_advanced_page.php?bug_id=0000551 |
|
|
- Umode +d tell any user who private you that you don't wish to recieve this message (IRCop may override it) it's +R like but it's apply to all non and registered users. That's not the purpose of +d. +d was designed ONLY for services. It was designed so that ChanServ could sit in #somechan and not have to listen to all the garbage. It was only expanded to allow users to use it because people asked for it. If it were up to me, +d would be U:line only as it was intended. +d doesn't even block all messages. For example, say something like "`hey there" and you'll see it, all text that begins with a ` is sent even if you are +d. That's because it was setup for in-channel commands (like `op). beta18 will take that one step further allowing the admin to define other characters, say !,@,etc. that will get through +d. In short, +d is not user friendly because it was not meant to be used by users. |
|
|
Oh I missed that one. Yeah, if you want that feature, use my usermode +D module (somewhere at vulnscan.org), it blocks all privmsgs except from ircops. Btw, I've been actually using +d now for a while, also because we now have set::channel-command-prefix like you said (I set it to '.'), that way ppl can have (multiple) bots in my chan without receiving all channel traffic 2 or 3 times. |
|
|
One new command I would like to see introduced to unrealircd is a mass gline removal. Meaning, removing glines on say :Reason. Example: Say you glined 20 zombie bots with the same :Reason "Zombies". I like to see a command that allows you to remove glines based on that ie., /glinec -c "zombie" Which will remove all glines with the word "zombies" in the :reason. Like setup an array to store the :reasons along with the IP/Host and purge it, based on the search criteria. Just a thought. |
|
|
Looks like 0000840 but then matched at the 'reason' field. |
|
|
Sort of something like that syzop on 0000840. I haven't ventured to look at the code fields, but since the reason field seems to be a text one. It would be simple to search on that field. Sort of using StrCmpr()to find the value glinec = StrCmpr(reason, "Zombie"). Shuffle all those found into an array using the var found along with the IP and purge it. edited on: 09-21-03 04:35 |
|
|
Spectre: coders know how to code, instead of technical suggestions, you should tell reasons why this feature would be nice to be implemented. Anyway, I agree with your idea, so if you're impatient to see this feature in UnrealIRCd (if it will ever be implemented) I recoded one of my modules, namely m_rmtkl, which now supports removing of any type of bans based on the reasons that ircops give. For more information, see http://angrywolf.linktipp.org/m_rmtkl.c (feel free to send bugreports to my email address). [I know this command needs better access control, I'll have done it later.] edited on: 09-21-03 12:46 |
|
|
I've finished the full access control for m_rmtkl. I hope that helps. |
|
|
I have a server using Unreal and we saw 3028 users. Generally 1500-2000. Maybe it isnt about the bug but "auspice" writes "imagine you run a 2000+ users network. don't say no such network running UnrealIRCd, it's will or it is" I didnt imagine, i saw. By the way +h mode can be good for users who arent ircop but helper (/helper nickname helperpass) even a host can be given them like "helper.freetibet.com". It is like a small gift to helpers. Think that they are helping ppl and even they dont have any right. And there is a default help channel option in conf so ppl who have +o there, can get +h, when they deop or leave channel, h mode can be taken back and host too....... ideas...ideas.. edited on: 09-24-03 20:20 |
|
|
Of these here is where I stand: 1.) Either make a new flag, or perhaps make it co-admin usable. 2.) I see no reason for such a thing. If you really want it, I believe AngryWolf has a "join and override" command somewhere. Also, I don't know why you are saying our SAJOIN is "wrong." That's your opinion. It is your opinion that SAJOIN is supposed to override everything and FJOIN is not. That's not the way we do it. And, even if I were to implement FJOIN I would not have reversed the two since that would only lead to confusion. 3.) The purpose of +h was to see /helpop notices. The /helpop notice system was designed so as to allow users to ask opers a question, but only those operators who are helpers. For example, user types "/helpop Can someone help me lookup my nickserv password?" Then helpops see, "*** HelpOp -- from TheNick (HelpOp): Can someone help me lookup my nickserv password?" Now how is someone who is +h -o going to deal with things like that? +h wasn't meant to just say "I know a lot of stuff" it was meant to say "I can help you with IRC op tasks". Therefore there is no reason, in my mind, to allow it to be used by non-opers. 4.) I'm thinking (it was suggested by someone else) of a SVSSNO since it would make my life easier rather than having to deal with crazy parsing in SVS[2]MODE. 5.) Umode +d does NOT block private messages, it blocks channel messages. It is designed for use by services and also bots that are designed only to listen for in-channel commands. Therefore, there what you are suggesting makes no sense. 6.) Already implemented. |
|
|
*close bug* To summarize: > - Make IRCop can use /DCCDENY and /UNDCCDENY not only for admin (we don't want 100 admins for just working on dccdeny). Just added in CVS (.2076) the can_dccdeny flag (as suggested by codemastr) > - Again make /FJOIN to force user join a channel but not override mode (IRCop) and /SAMODE to force yourself join a channel and override any mode (+a). *ignore /fjoin crap*.. anyway, we modded /sajoin to go trough all modes (this was mentioned in another bugreport/feature request) > - Make, umode +h stay even if you dont'have umode +o but you can't +h yourself and it's loose when you -o. (our network need helpop that can listen to chatops message but not an IRCop) Rejected. > - Is SVS2MODE support nomask? I seem can't make it to work please add it if you can. Seperate bugreport 0001461 - Umode +d tell any user who private you that you don't wish to recieve this message (IRCop may override it) it's +R like but it's apply to all non and registered users. Rejected. - /kline /zline /gline /gzline /shun default expiry don't make it permanence, if expiry not given the expire time would be the default one. Added in September 2003 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-09-15 16:14 | auspice | New Issue | |
| 2003-09-15 18:38 | AngryWolf | Note Added: 0003655 | |
| 2003-09-15 19:46 | auspice | Note Added: 0003656 | |
| 2003-09-15 22:54 | Rocko | Note Added: 0003660 | |
| 2003-09-16 03:49 | syzop | Note Added: 0003663 | |
| 2003-09-16 03:56 | syzop | Summary | I feature I wish to see in beta 18 or maybe the final release => Some suggestions... |
| 2003-09-16 05:02 | AngryWolf | Note Added: 0003665 | |
| 2003-09-16 05:06 | AngryWolf | Note Edited: 0003665 | |
| 2003-09-16 13:38 | syzop | Note Added: 0003666 | |
| 2003-09-16 14:36 | auspice | Note Added: 0003667 | |
| 2003-09-16 14:45 | muhQ | Note Added: 0003668 | |
| 2003-09-16 14:58 | auspice | Note Added: 0003669 | |
| 2003-09-16 15:56 | syzop | Note Added: 0003670 | |
| 2003-09-18 18:45 | Rocko | Note Added: 0003679 | |
| 2003-09-18 19:03 | Rocko | Note Added: 0003680 | |
| 2003-09-18 21:52 |
|
Note Added: 0003682 | |
| 2003-09-18 22:58 | syzop | Note Added: 0003683 | |
| 2003-09-21 03:13 | Spectre | Note Added: 0003695 | |
| 2003-09-21 03:33 | syzop | Note Added: 0003696 | |
| 2003-09-21 04:32 | Spectre | Note Added: 0003698 | |
| 2003-09-21 04:35 | Spectre | Note Edited: 0003698 | |
| 2003-09-21 12:06 | AngryWolf | Note Added: 0003699 | |
| 2003-09-21 12:46 | AngryWolf | Note Edited: 0003699 | |
| 2003-09-21 15:11 | AngryWolf | Note Added: 0003705 | |
| 2003-09-24 20:12 | LoVeR | Note Added: 0003713 | |
| 2003-09-24 20:20 | LoVeR | Note Edited: 0003713 | |
| 2004-01-18 01:44 |
|
Note Added: 0004726 | |
| 2004-02-05 01:35 | syzop | Status | new => closed |
| 2004-02-05 01:35 | syzop | Note Added: 0004880 |
