View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001899 | unreal | ircd | public | 2004-06-26 03:47 | 2004-07-18 18:42 |
Reporter | parker182 | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | resolved | Resolution | fixed | ||
Summary | 0001899: Add oper::usermodes | ||||
Description | It would be nice to be able to set usermodes that would be given to certain opers when the oper up. This would be similar to snomask in oper{} but for normal umodes. Something like this swhois <whois info>; usermodes <usermodes>; <-- snomask <snomask>; This way I could set some opers that I would like to be +q (Only U:Lines can kick you (Services Admins Only)) | ||||
Tags | No tags attached. | ||||
3rd party modules | |||||
has duplicate | 0001844 | resolved | set::modes-on-oper causing unauthorized opers to get flag +q? |
|
why don't add the +q-allowed operflag, and the oper may activate this mode on will? |
|
Because I already have the can_setq flag enabled, and it's easier to just have the server set it without depending on the oper to have it in remotes, or remembering to set the mode on /oper. Also because maybe +q isn't the only mode that can be set during /oper for certain opers. I may also want umode +H for one oper, but not the other. |
|
still rather senseless - if you can't trust your opers using their modes properly, you have a problem... - if you feel in need to force your opers into modes, you have a problem... - if you have forced them into some modes they may change them afterwards by will, which doesn't resolve anything... just my 2 cents... |
|
I didn't ask for a debate or comments on how senseless my feature request is, I simply asked for a feature that's not in any current version of Unreal. The devs either like the idea and include it in future versions, or they don't like it and decide it's not worth the time to include it in future versions. Thank you though. Your 2 cents have been taken into consideration |
|
Well, I don't find it a bad idea. I mean, we have a setting for individual snomasks, why not for modes? Besides q there are some other ones that opers could want.. like v, H, W (well, we have get_umodew for that), etc.. Also as mentioned in another thread.. setting q in modes-on-oper (which is a setting that applies to all opers) gives all opers +q regardless of their access level, so implementing this would resolve that issue. edited on: 2004-06-28 23:00 |
|
Yeah, I think having an oper::modes would be better than having those get_* things, which could then be removed. However, we then run into more issues like the modes-on-oper. I see it now, "I added +q to oper::modes, but the oper doesn't have can_setq and it still gives it to him!!!" |
|
Thank you guys for your feedback. /me can't wait for the next release =) |
|
>I see it now, "I added +q to oper::modes, but the oper doesn't have can_setq >and it still gives it to him!!!" In which case, the admin really does fulfill the song "If I Only Had a Brain..." <rant> I mean, come on! You don't give the oper can_setq, services-admin, or netadmin; why the DEVIL would you try to have him +q on oper? I can understand the wierdness with the set:: version, but for oper::? Doing that really is just plain stupid :) and any admin that tries it should NOT be running _any_ kind of IRCd, Unreal or otherwise. Heck, any admin that tries it should be dragged out to the street and shot... </rant> Other than that, it does seem like a good idea :) . |
|
Obviously this won't get into 3.2.1 since we are in a feature freeze already, but I'm (pretty) sure it will be in 3.2.2 :). |
|
hmm. the net i am on now employs that set::modes-on-oper thing, but, as one of you said, what if we dont like the forced modes? for instance, i hate being set +ipH and unfortunately, when you do /mode mynick -ipH, the IRCd unsets modes it thinks you shouldnt have (like an unauthorized +q) -- and having that mode in your o:line fixes that. oh, and I rewrote some of the source for the ircd... giving me the following results: -mode +q sets automatically on oper if you have can_setq in the oline -mode +q is not removed from you if you set another mode (provided it's in your o:line) =D wasn't hard to fix that, just a few changes to m_oper and such.... :) |
|
"-mode +q sets automatically on oper if you have can_setq in the oline" That isn't a bad idea. Unfortunately, I'm not using linux at the moment, and compiling from source on Win32 is a pain in the arse. I still like the oper::modes idea, instead of tweaking the source. However, I would tweak the source in a heartbeat, when given the opportunity, on a seperate install of course. As for being forced modes. If an admin wants those modes set when you oper, I'm sure there is a reason behind his/her decision. When in doubt, ask. |
|
Added in .103 |
Date Modified | Username | Field | Change |
---|---|---|---|
2004-06-26 03:47 | parker182 | New Issue | |
2004-06-26 08:54 | medice | Note Added: 0006784 | |
2004-06-26 16:13 | parker182 | Note Added: 0006786 | |
2004-06-28 19:12 | medice | Note Added: 0006801 | |
2004-06-28 19:47 | parker182 | Note Added: 0006802 | |
2004-06-28 23:00 | syzop | Note Added: 0006803 | |
2004-06-28 23:00 | syzop | Note Edited: 0006803 | |
2004-06-28 23:47 |
|
Note Added: 0006804 | |
2004-06-29 00:25 | parker182 | Note Added: 0006805 | |
2004-06-29 18:13 | aquanight | Note Added: 0006811 | |
2004-06-29 18:27 | syzop | Note Added: 0006812 | |
2004-06-29 18:28 | syzop | Reproducibility | always => N/A |
2004-06-29 18:28 | syzop | Status | new => acknowledged |
2004-06-29 18:28 | syzop | ETA | none => < 1 month |
2004-06-29 18:28 | syzop | Summary | Set umodes on oper up => Add oper::usermodes |
2004-07-06 22:10 | Zell | Note Added: 0006911 | |
2004-07-08 11:00 | parker182 | Note Added: 0006924 | |
2004-07-12 15:46 |
|
Status | acknowledged => assigned |
2004-07-12 15:46 |
|
Assigned To | => codemastr |
2004-07-18 18:42 |
|
Status | assigned => resolved |
2004-07-18 18:42 |
|
Resolution | open => fixed |
2004-07-18 18:42 |
|
Note Added: 0007143 | |
2007-04-19 02:56 |
|
Relationship added | has duplicate 0001844 |