View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002644 | unreal | ircd | public | 2005-09-20 11:56 | 2005-10-15 19:31 |
| Reporter | ultrotter | Assigned To | syzop | ||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | i386 | OS | Linux | OS Version | 2.6.11 |
| Product Version | 3.2.3 | ||||
| Fixed in Version | 3.2.4 | ||||
| Summary | 0002644: Oper override invite and oper auto join conflict... | ||||
| Description | Hi! I think that the feature that requires an oper to invite himself before joining channels that would otherwise be restricted (+i,+s,+p) is very useful. On the other hand I feel that when a channel is specified in the oper-auto-join list the oper should be made join it regardless of the safety on override being turned on! This is because if the network requires that opers are present on some channels, then even if those channels are for other reasons +s, or +i, the oper should join on /oper, not just receive an error and than have to invite himself and join, manually! | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
and how would the list be maintaned? i mean, its ok having this, but to me its so easy to abuse. 8 servers, how is all servers going to know the rooms? of course in conf file is fine, however someone can easily add 1 room in there that the others dont have, and then theres a problem, server 1 has #admin and server 2 has #admin and #opers, this would cause problems? (or would it) |
|
|
If I understand what he means, it's just that in case of an auto join due to set::oper-auto-join, those channels should be exempted from the /invite-before-joining-p/s-channels restriction. Sounds fine to me. EDIT: Actually the same applies to set::auto-join too, although it makes little sense for such channels to be +s, but why not ;). |
|
|
Yeah, that was what I meant... Since both are local server policy I think it would make sense that one overrides the other! Thanks! :) Also I think this applies more to the oper auto join, than to the auto join, since one is suppose to login to the server (and then auto join applies) and later on do /oper, and at that point the restriction of having to invite himself, which applies only to ircops, starts to apply to him... Correct me if I'm wrong... |
|
|
[quote]EDIT: Actually the same applies to set::auto-join too, although it makes little sense for such channels to be +s, but why not ;).[/quote] Except set::auto-join goes off before the user has a chance to /oper therefore no operoverride or anything of the sort. (EDIT: or did that get changed or something?) |
|
|
i can see where this idea is coming from, but in my opinion it is a little strange - why should standard users be able to just walk into a +s/p room and not have to invite themselves? I join plenty of +s channels on my network, i have every right to be in them, that does not mean i want to override to enter my own channels or even put them in my auto join on oper list. Also, i could deoper, join a room and avoid the override notice if i was really trying to be malicious If this is a concern that opers are abusing their ability to see hidden channels then i would suggest a /list flag that enables them to see hidden channels, when they don't use the flag they just see normal viewable channels |
|
|
Or perhaps adding another oper flag to allow/deny the ability to list secret channels... I know people prefer to add less oper flags, but if people don't trust their opers enough to leave +s/+p channels alone, they should not be making those people opers! I think the feature that forces opers to /invite themselves is pointless... Why deny the oper the ability to just join it, but give the oper an even more abusive ability (oper override)? |
|
|
This is an optional feature, which obviously you two (Bugz/pak) don't intend to use, that's fine, but some people that have a strict policy of "ircops should not intervene in channels" do like such a feature. I'm sure people actually using this feature can better explain why they use it :). |
|
|
Added in .389. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-09-20 11:56 | ultrotter | New Issue | |
| 2005-09-21 10:06 | White_Magic | Note Added: 0010496 | |
| 2005-09-21 11:17 | syzop | Note Added: 0010497 | |
| 2005-09-21 11:17 | syzop | Status | new => acknowledged |
| 2005-09-21 11:18 | syzop | Note Edited: 0010497 | |
| 2005-09-21 11:19 | syzop | Note Edited: 0010497 | |
| 2005-09-21 13:00 | ultrotter | Note Added: 0010498 | |
| 2005-09-21 13:01 | ultrotter | Note Edited: 0010498 | |
| 2005-09-21 22:15 | aquanight | Note Added: 0010502 | |
| 2005-09-21 22:16 | aquanight | Note Edited: 0010502 | |
| 2005-09-27 05:31 | pak | Note Added: 0010516 | |
| 2005-09-27 06:23 | Stealth | Note Added: 0010517 | |
| 2005-09-27 11:21 | syzop | Note Added: 0010518 | |
| 2005-10-15 19:31 | syzop | Status | acknowledged => resolved |
| 2005-10-15 19:31 | syzop | Fixed in Version | => 3.2.4 |
| 2005-10-15 19:31 | syzop | Resolution | open => fixed |
| 2005-10-15 19:31 | syzop | Assigned To | => syzop |
| 2005-10-15 19:31 | syzop | Note Added: 0010587 |
