View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002731 | unreal | ircd | public | 2005-12-28 21:20 | 2015-07-13 22:14 |
| Reporter | Stealth | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.4 | ||||
| Summary | 0002731: can_override as umode | ||||
| Description | I think can_override would be better if it were assigned a umode. Then the oper would be able to choose when s/he wants to have it enabled, and when s/he does not. | ||||
| 3rd party modules | |||||
|
|
hm, why? to override, you have to invite yourself first anyway (not like you override by accident..) |
|
|
I was referring more to channel things like kicking/modes |
|
|
Ah ok. Maybe a good idea then... |
|
|
99.9% people would set this umode just after oper'ing, I'm sure.. |
|
|
Some people do a lot of things that isn't right... Like setting umode q when they oper. They can do what they want, but I am sure some people (like me) would like to be able to freely enable/disable oper override. For example: I have a small network, and with any network abusive users come in and cause problems. I know how to use the proper commands to take care of 1 or 2 at a time if I need to, so I don't need oper override. However, if there is a whole channel of them, I would be able to set the umode and be able to take care of them before they know it. |
|
|
How about a comprimise? I like the idea Bugz is suggesting, however, what if you could freely set/remove the usermode IF you had the "can_override" flag set in your operblock. This would prevent abusive overriding and usage of the mode as well as accidental overrides! |
|
|
That is exactly what I had in mind... Exactly as umode q, but not automatically included in any levels :) |
|
|
Good idea. We've got a lot of free space in the Unreal umode struct... (syzop is gonna shoot me for sayin that lol) I've played around with the umode stuff before, its fairly easy to add umodes and umode checks. I've used umode for a few stupid things <yeah, i modify my source -- but I dont recommend it, takes a lot of work to not crash things>. I'd love to see this request added. |
|
|
"For example: I have a small network, and with any network abusive users come in and cause problems. I know how to use the proper commands to take care of 1 or 2 at a time if I need to, so I don't need oper override. However, if there is a whole channel of them, I would be able to set the umode and be able to take care of them before they know it." Just because you've got oper override doesn't mean you need to use it. You can have it on you and simply do nothing with it. I keep it on all the time but I don't think I've ever had to use it on my network. I think this works best as a oper flag instead of a mode. |
|
|
Back when I owned a channel, I set modes VERY often. So every time I didn't check everything perfectly, I'd unintentionally use override. Having a umode for override would be better than accidentally setting it off all the time. |
|
|
Strawberry_Kittens, think before you speak. It's a good idea and the basis is there. Everyone does their own thing on their own networks, but I too have been caught using oper_override by accident when i didn't need to, just wasn't identified or some shit like that. It would be nice to set it when needed, and off when not (especially if i'm leaving my computer and don't want to lock it) |
|
|
We've got enough usermodes that are oper-only. Usermodes should be there for the end-user to use. All the oper ones cluttered shit up. Why not make 1 oper-only mode 'o', then just have everything else oper-related an extension of that mode. Like snomasks are setup. ex: /mode name +O +N = net admin /mode name +O +o = Global op /mode name +O +O = local op /mode name +O +Nq = Network admin that has +q enabled & can only be kicked by U:Lines /mode name +O +oq = Global op that has +q enabled & can only be kicked by U:Lines ect. Seems like a better way to implement the oper-only modes since if you're adding a user-mode for everything opers can/can't do it's going to be full of things that none of the users are going to give a shit about. This also saves room for more module-added modes. |
|
|
why just not use 'long long' to emulate 64 bits for umodes? =) |
|
|
My plan is to move override to usermode +p as has been done in various other IRCds, and then have it on a timer, as has been done in various other IRCds. That makes using the override feature a conscious decision. |
|
|
And what of user mode +p's current use? (Hides channels from WHOIS) |
|
|
Okay... usermode +P then. :P |
|
|
I think it's ok now with 3.4.x without the umode. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-12-28 21:20 | Stealth | New Issue | |
| 2005-12-28 21:27 | syzop | Note Added: 0010906 | |
| 2005-12-28 21:53 | Stealth | Note Added: 0010907 | |
| 2005-12-29 09:00 | syzop | Note Added: 0010908 | |
| 2005-12-29 09:00 | syzop | Note Edited: 0010908 | |
| 2006-01-01 06:18 | pinstrate | Note Added: 0010911 | |
| 2006-01-01 13:05 | Stealth | Note Added: 0010912 | |
| 2006-01-07 10:10 | Dodge_Ram | Note Added: 0010948 | |
| 2006-01-07 18:03 | Stealth | Note Added: 0010950 | |
| 2006-01-16 23:55 | Zell | Note Added: 0010974 | |
| 2007-04-27 04:27 |
|
Status | new => acknowledged |
| 2008-07-27 13:45 | Strawberry_Kittens | Note Added: 0015327 | |
| 2008-07-27 13:46 | Strawberry_Kittens | Note Edited: 0015327 | |
| 2008-08-25 04:59 | Shining Phoenix | Note Added: 0015372 | |
| 2008-08-26 23:24 | Bricker | Note Added: 0015376 | |
| 2008-09-29 03:22 | Strawberry_Kittens | Note Added: 0015404 | |
| 2008-09-29 21:36 | argvx | Note Added: 0015405 | |
| 2013-05-06 07:40 |
|
Note Added: 0017504 | |
| 2013-05-07 14:58 | Jobe | Note Added: 0017531 | |
| 2013-05-07 16:32 |
|
Note Added: 0017532 | |
| 2015-07-13 22:13 | syzop | Note Added: 0018484 | |
| 2015-07-13 22:13 | syzop | Status | acknowledged => closed |
| 2015-07-13 22:14 | syzop | Assigned To | => syzop |
| 2015-07-13 22:14 | syzop | Resolution | open => no change required |
