View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002040 | unreal | ircd | public | 2004-08-24 02:05 | 2013-05-07 06:24 |
| Reporter | aquanight | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | X86 | OS | Windows | OS Version | XP Professional |
| Product Version | 3.2.1 | ||||
| Target Version | 3.3-alpha0 | Fixed in Version | 3.4-alpha1 | ||
| Summary | 0002040: +L without +l? | ||||
| Description | +L requires +l before being set. But unsetting +l does not remove +L - regardless of who does it (uline, ircop, chan owner, chanop, whatever). | ||||
| Steps To Reproduce | - Usermode -o and the works. - Create and register a channel. Don't mlock either of +l or +L. Hop to get +q/~. - Set +lL 1 #Anything - Set -l, and notice +L remains. Even MODE-read still shows +L being there. | ||||
| Additional Information | If +L is useless without +l, shouldn't both be unset at the same time? | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
is there a need for -L om l? maybe someone wants to disable the limit but reinstall it later on - so it's more comfortable if +L stays in the meantime ans he has not to care for it... on another point of view L is owner-only (if I remember correctly) and +l is not - so you enable the unset of this mode to non-owners as well... |
|
|
Hm... yes I thought of this. >maybe someone wants to disable the limit but reinstall it later on - so it's more comfortable if +L stays in the meantime ans he has not to care for it.. I'm thinking that typically +l and +L would be set in mlock - at least when used together. I can imagine using +l for join controls (though +f does a better job of this :P ), but in such a case would you use +L? I don't quite see the point in sending massjoinflooders to a different channel - flooding it instead :) . Also, there's a way to "disable the limit" but still leave the channel +l: (try to) set the limit to 2147483647 which is probably the effective limit when -l :P . >on another point of view L is owner-only (if I remember correctly) and +l is not - so you enable the unset of this mode to non-owners as well.. I had considered that if this were done, +l wouldn't be able to be unset (maybe changed to a different number, but not to "set" to 0 (aka unset)) for the reason you mentioned that nonowners would otherwise become able to -L... I guess what we'd need is to look and see how +L is being used (if it's being used :/ )... maybe... problem is I don't know anyone that uses +L :P maybe the coders do... *poke* |
|
|
I use +L personally, a useful tool for locking say, filesharing channels. Redirect them to the main channel (>:)). The one thing I don't like about +L is it is owner-only, meaning if you don't have services, you have to +q yourself to use it. Makes sense, I suppose... but yeah. :) "if you cant trust your chanops, dont make them chanops" >:) |
|
|
Well I notice that with +i and +K, -i also does -K: -> MODE #Test +iK <- :[email protected] MODE #Test +iK -> MODE #Test -i <- :[email protected] MODE #Test -iK So in a way, it's inconsistant. /me wonders what other modes should be tried... In this case, I can understand: +K is meaningless because /KNOCK can't be used on a channel that isn't +i (though +R isn't enough either?). But on the same token, +L has no meaning on a "limitless" channel. |
|
|
Maybe +L should always redirect the users if +l isn't set |
|
|
>Maybe +L should always redirect the users if +l isn't set That can be acheived with +l - set it to 1 :P . |
|
|
Yes, but then there is no reason to remove +L on -l so this "bug" could be closed :p |
|
|
> Yes, but then there is no reason to remove +L on -l so this "bug" could be closed :p I don't see where you get that logic from. You were suggesting +L do something without +l. The point is: it doesn't, so why does it "stick around" without it's partner? |
|
|
You say +L should be unset at the same time as +l, but there is this +L=owner-only problem. So why don't make +L an independent mode and forget -L on -l. |
|
|
:/ I already metioned how this could be handled: if +L is set, a normal chanop could be prevented from doing -l at all, but using +l to change the limit would be okay. |
|
|
+L is a handy feature for large channels. Suppose your channel usually gets 80 people. You wouldn't want them all talking at once in #channel-1, so you'd set +lL 40 #channel-2. This feature should stay in the IRCd. I don't see the reason to set -L on -l. What if someone wants to temporarily stop the channel link? For example, unset +l and then set it again later? I don't see why this mode should be changed. +L is also set for channel owner for a reason; You wouldn't want any op to just link your channel to his. This should not be changed. |
|
|
>I don't see the reason to set -L on -l. What if someone wants to temporarily >stop the channel link? For example, unset +l and then set it again later? I >don't see why this mode should be changed. As I mentioned, in most cases you'd probably have +l mlocked or something. If you have a floating limit however, then it is possible to "disable" it by simply changing the limit to a ridiculously high value. Besides, if you can't trust the chanops, why are they chanops? |
|
|
"Besides, if you can't trust the chanops, why are they chanops?" Ok, if you've ever understood the purpose of a hierarchy, you'll know my whole point. Take an army, for example. People don't just go from Private to Warrant Officer right away. They do however, get to the next step: the rank of Corporal. The Warrant Officer can lead the platoon, whereas the Corporal can only lead a squad of four inside the platoon. Now, you're saying this: Why shouldn't the Corporal be able to lead the whole platoon? (if you can't trust the chanops, why are they chanops? --> if you can't trust the Corporals, why are they Corporals?). It all comes down to the hierarchy system. You don't just give someone full privileges right away. |
|
|
Hm... it's not quite the same thing... Giving someone chanop on a channel is usually a sign of trust. Would you give ops to just any random person that asked for it? Probably not. *pokes coders* |
|
|
maybe the purpose is coz of "thinking ahead" - add a limit, add a +L link, remove the limit, in a flood, simple add the limit and you *dont* need to the add the link coz it there... same story with +K, add +i add +K, remove the +i, and ur reassured the next time u set +i u *WONT* get a Knock flood becuz +K was never removed in the first place.... *edit* prevention is better than cure... edited on: 2004-09-04 16:40 |
|
|
Um. No. +K *IS* removed when you set -i. |
|
|
This should behave identical to +i/+K regardless of how we actually want both mode sets to behave. Let's recap: You CANNOT set +K without +i. You CANNOT set +L without +l. +K without +i is worthless, it does nothing, knocking isn't allowed unless +i is set. +L without +l is worthless, it does nothing, joining won't kick you to a different channel unless +l is set and the limit is reached. Now, allowing the modes to remain set so that a user can simply +i or +l a channel and let the defaults take over certainly would be nice, as it makes it easier for the user. But disabling the modes automatically also makes it easier for the user who uses them in the ways intended. Here's what I think should happen: If a set of modes such as i/K, l/L can coexist or exist on its own without causing any behavior issues in Unreal, then I think we should leave it up to the user to decide what they want to do. In this case, the user could set +L and +K without +l or +i being set. The only problem I can see with this is that users who don't fully understand what the modes are for won't then have the incite given to them by the errors that are currently provided. So it seems to come down to: Would allowing users to set the modes and remove them manually be an issue? Is it worth the possibility of confusing users? And if not, then we simply make +l/+L behave exactly as +i/+K, and -L when -l is set. |
|
|
WolfSage: Microsoft Word does stuff that the programmers thought would be helpful. I hate it. Changing user's channel modes for them is similar. I think we should let them set unset iKlL whenever they want, and not have the server do it for them. |
|
|
+l should remove +L due to the fact on net.join +L won't be set cos +l isn't set, and we have a desync. |
|
|
Your logic here baffles me Sts =) |
|
|
what sts is saying, i believe, is that the modes arnt reset after a netsplit or during desync, so the server trying to force +L which cannot be set without +l would break something. This has been an issue for quite some time, and should have been fixed, but i guess its going to be now |
|
|
Another issue. +L can only be set/unset by +q users.. if we allow -l to take away +L, we would subvert this .. just noticed this while trying to add this functionality. |
|
|
when +L is active only allow +q to remove -l |
|
|
WolfSage suggest making the modes independent (ie, +L doesnt require +l to be set), which is feasible. Any comments? This will break backwards compatibility, but it is needed :P |
|
|
Patched in .2387, removing dependancy on +l for +L. This will be backwards compatible as well, SJOIN doesn't care (TM) and mode doesn't either in case of a server sending it. So this will be just a client protocol modification. Also pulled out a modification that got in accidentially. The reason it is feasible is due to the fact +l 0 and +l 1 will be, honestly, the same, and we can read +l 0 as being +l 1 if the channel has one user that keeps it open. |
|
|
Although I personally wouldn't care much, it seems there's a tendency to decouple these modes. So we'd need to re-port this patch from old 3.3 to new 3.3. |
|
|
I decoupled this a while ago. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-08-24 02:05 | aquanight | New Issue | |
| 2004-08-24 09:09 | medice | Note Added: 0007420 | |
| 2004-08-25 02:20 | aquanight | Note Added: 0007422 | |
| 2004-08-26 05:46 | w00t | Note Added: 0007427 | |
| 2004-08-26 20:29 | aquanight | Note Added: 0007432 | |
| 2004-08-26 22:46 | yodaone | Note Added: 0007433 | |
| 2004-08-27 02:31 | aquanight | Note Added: 0007438 | |
| 2004-08-27 19:51 | yodaone | Note Added: 0007439 | |
| 2004-08-28 05:46 | aquanight | Note Added: 0007444 | |
| 2004-08-28 08:52 | yodaone | Note Added: 0007446 | |
| 2004-08-28 19:07 | aquanight | Note Added: 0007447 | |
| 2004-08-31 02:23 | al5001 | Note Added: 0007465 | |
| 2004-08-31 02:27 | aquanight | Note Added: 0007466 | |
| 2004-09-03 04:38 | al5001 | Note Added: 0007480 | |
| 2004-09-03 15:39 | aquanight | Note Added: 0007481 | |
| 2004-09-04 16:38 | White_Magic | Note Added: 0007520 | |
| 2004-09-04 16:40 | White_Magic | Note Edited: 0007520 | |
| 2004-09-04 16:41 | aquanight | Note Added: 0007521 | |
| 2006-01-22 13:59 | syzop | Relationship added | has duplicate 0002757 |
| 2007-04-16 10:40 |
|
Relationship added | has duplicate 0002805 |
| 2007-04-17 17:41 | WolfSage | Note Added: 0013485 | |
| 2007-04-17 17:42 | WolfSage | Note Edited: 0013485 | |
| 2007-04-17 17:44 | WolfSage | Note Edited: 0013485 | |
| 2007-04-18 04:51 | Shining Phoenix | Note Added: 0013496 | |
| 2007-04-18 04:54 |
|
Relationship added | has duplicate 0003240 |
| 2007-04-18 04:59 |
|
Note Added: 0013501 | |
| 2007-04-18 04:59 |
|
Status | new => acknowledged |
| 2007-04-18 19:48 | WolfSage | Note Added: 0013560 | |
| 2007-04-18 22:40 | Bricker | Note Added: 0013570 | |
| 2007-04-27 13:13 |
|
Note Added: 0013892 | |
| 2007-04-27 13:28 | vonitsanet | Note Added: 0013893 | |
| 2007-04-28 08:26 |
|
Note Added: 0013910 | |
| 2007-05-04 08:36 |
|
Status | acknowledged => resolved |
| 2007-05-04 08:36 |
|
Fixed in Version | => 3.3-alpha0 |
| 2007-05-04 08:36 |
|
Resolution | open => fixed |
| 2007-05-04 08:36 |
|
Assigned To | => stskeeps |
| 2007-05-04 08:36 |
|
Note Added: 0013998 | |
| 2011-07-19 14:05 | syzop | Assigned To | stskeeps => |
| 2011-07-19 14:05 | syzop | Status | resolved => needs re porting |
| 2011-07-19 14:08 | syzop | Note Added: 0016704 | |
| 2011-07-19 17:11 | syzop | Target Version | => 3.3-alpha0 |
| 2013-05-07 06:24 |
|
Note Added: 0017517 | |
| 2013-05-07 06:24 |
|
Status | needs re porting => resolved |
| 2013-05-07 06:24 |
|
Fixed in Version | 3.3-alpha0 => 3.4-alpha1 |
| 2013-05-07 06:24 |
|
Assigned To | => nenolod |
