View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003061 | unreal | ircd | public | 2006-09-11 21:10 | 2006-11-25 08:27 |
| Reporter | Robby22 | Assigned To | |||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | unable to duplicate | ||
| Product Version | 3.2.5 | ||||
| Summary | 0003061: "MODE #channel" no longer shows extended chanmodes to ircops since the CVS change to it | ||||
| Description | It concerns this change: "- Fixed bug in MODE #channel showing extended channel mode parameters when not in #channel." Since it got changed, this behaviour now also applies to ircops and higher (like netadmins), now they also can't see the extended channel modes when not in the channel... I don't think it is actually intended to be like this and is probably a mistake, or is it? Or maybe make it so that only admins/netadmins see the extended modes (be it through an option) or something like that... | ||||
| Steps To Reproduce | Install CVS version 1.1.1.1.2.1.2.1.2.2234.2.562, set a another client on a channel so it keeps it open and set modes like +k and +f on that channel, part that channel and do /mode <channel> while being opered, and it won't show the parameters of these modes despite being opered. | ||||
| 3rd party modules | |||||
|
|
I think opers should be able to see this, but it should be restricted to NetAdmins ifndef SHOW_SECRET |
|
|
Yeah, I was thinking something along those lines too, hence why I mentioned to make it an option, but I don't know if SHOW_SECRET is related enough to this situation, since it's actually meant to hide +s channels from ircops, except netadmins when undefined. Maybe SHOW_SECRET should be renamed to something else to fit those two options (hide/show secret channels AND extended chanmodes), or a new define or configfile option should be created for "hide/show extended chanmodes". |
|
|
It isn't whether or not to show secret channels, but the access level to show them to. |
|
|
I know, but adding the option to show/hide extended chanmodes to that same define is a bit, how shall I say this... unrelated to the purpose of that define? As non-secret channels also can have extended chanmodes... Or SHOW_SECRET would have to be renamed to something appropriate to accommodate the two options, since now it is only meant for show/hide secret channel uses, as also specified by the description of that define... |
|
|
Agreed. It should probably its own, but the testing you did with me made me think immediately of seeing the key as an oper without generating the operoverride globals. That example would be in line with show_secret more. Should get its own define. |
|
|
Well, maybe, but that behaviour is like this for a while now.. (well, except since this CVS change..), one, while opered, can see keys and other extended (like +f) parameters without being on the channel and without an OperOverride notice. You would suggest to send out an override notice for every oper that does a "MODE #channel"? Or even only if it has +k set? |
|
|
The bug that was fixed was that EXTENDED channel mode parameters were accidently shown when outside the channel. Extended channel modes is a subsystem besides normal chanmodes at this time, it's a technical term. The only extended parameter channel mode that was loaded by default was 'j'. So in short, you never could have seen the +k key, or anything like that through this (I verified this on 3.2.5 before I committed this, and now again), since all those other parameter modes were not extended channel modes. Example from in chan: #somechan +ntkfj haha [5t]:10 3:3 Example from outside chan as an IRCOp: #somechan +ntkfj 3:3 And that's the bug.. nothing more, nothing less :P. The key was never shown. Why we don't show all paramters to opers outside the channel? Because it can potentially undo all the operoverride stuff. If the channel is +sntk, and the oper would see the key, (s)he could simply join with that key without causing an operoverride (naturally) because the person is not overriding... EDIT: clarified that example 2 was outside the channel _by an oper_ |
|
|
@syzop: Well, while testing Jason did tell me the correct key the channel was set to and he was not on it... So I'm a bit confused as to why he can see the key if you say it was never shown in the first place... ;) |
|
|
Me too, I'm waiting for his reply on how he acquired those magic powers ;) |
|
|
Err.. I don't remember specific incidents in testing from months ago... If I wanted to figure it out, I would probably try things in this order. Someone pull out a copy of that version and get testing (I was a netadmin) Do whatever Robby suggested. (I would never have thought to test this myself) /list /mode #chan /mode #chan +k I'm out of ideas now. Perhaps I had another one then. |
|
|
Ok, then it can be closed. As said in a few posts ago, I already tested this prior to changing things, and it didn't work. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-09-11 21:10 | Robby22 | New Issue | |
| 2006-09-11 21:15 | JasonTik | Note Added: 0012380 | |
| 2006-09-11 21:16 | JasonTik | Note Edited: 0012380 | |
| 2006-09-11 21:31 | Robby22 | Note Added: 0012381 | |
| 2006-09-11 21:39 | JasonTik | Note Added: 0012382 | |
| 2006-09-11 21:55 | Robby22 | Note Added: 0012383 | |
| 2006-09-11 21:59 | JasonTik | Note Added: 0012384 | |
| 2006-09-11 22:18 | Robby22 | Note Added: 0012385 | |
| 2006-09-12 05:22 | syzop | Note Added: 0012387 | |
| 2006-09-12 05:27 | syzop | Note Edited: 0012387 | |
| 2006-09-12 12:51 | Robby22 | Note Added: 0012389 | |
| 2006-09-13 06:36 | syzop | Note Added: 0012390 | |
| 2006-09-13 06:37 | syzop | Note Edited: 0012390 | |
| 2006-11-24 16:10 | JasonTik | Note Added: 0012724 | |
| 2006-11-25 08:27 | syzop | Status | new => closed |
| 2006-11-25 08:27 | syzop | Note Added: 0012727 | |
| 2006-11-25 08:27 | syzop | Resolution | open => unable to duplicate |
