View Issue Details

IDProjectCategoryView StatusLast Update
0002040unrealircdpublic2013-05-07 06:24
ReporteraquanightAssigned Tonenolod 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformX86OSWindowsOS VersionXP Professional
Product Version3.2.1 
Target Version3.3-alpha0Fixed in Version3.4-alpha1 
Summary0002040: +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 InformationIf +L is useless without +l, shouldn't both be unset at the same time?
TagsNo tags attached.
3rd party modules

Relationships

has duplicate 0002757 closed channel modes +lL 
has duplicate 0002805 closed Simple mode error 
has duplicate 0003240 closed A small tweak to a channel mode 

Activities

medice

2004-08-24 09:09

reporter   ~0007420

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...

aquanight

2004-08-25 02:20

reporter   ~0007422

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*

w00t

2004-08-26 05:46

reporter   ~0007427

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" >:)

aquanight

2004-08-26 20:29

reporter   ~0007432

Well I notice that with +i and +K, -i also does -K:

-> MODE #Test +iK
<- :aquanight!~aquanight@netadm.dragons.net MODE #Test +iK
-> MODE #Test -i
<- :aquanight!~aquanight@netadm.dragons.net 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.

yodaone

2004-08-26 22:46

reporter   ~0007433

Maybe +L should always redirect the users if +l isn't set

aquanight

2004-08-27 02:31

reporter   ~0007438

>Maybe +L should always redirect the users if +l isn't set

That can be acheived with +l - set it to 1 :P .

yodaone

2004-08-27 19:51

reporter   ~0007439

Yes, but then there is no reason to remove +L on -l so this "bug" could be closed :p

aquanight

2004-08-28 05:46

reporter   ~0007444

> 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?

yodaone

2004-08-28 08:52

reporter   ~0007446

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.

aquanight

2004-08-28 19:07

reporter   ~0007447

:/

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.

al5001

2004-08-31 02:23

reporter   ~0007465

+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.

aquanight

2004-08-31 02:27

reporter   ~0007466

>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?

al5001

2004-09-03 04:38

reporter   ~0007480

"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.

aquanight

2004-09-03 15:39

reporter   ~0007481

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*

White_Magic

2004-09-04 16:38

reporter   ~0007520

Last edited: 2004-09-04 16:40

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

aquanight

2004-09-04 16:41

reporter   ~0007521

Um. No. +K *IS* removed when you set -i.

WolfSage

2007-04-17 17:41

reporter   ~0013485

Last edited: 2007-04-17 17:44

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.

Shining Phoenix

2007-04-18 04:51

reporter   ~0013496

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.

stskeeps

2007-04-18 04:59

reporter   ~0013501

+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.

WolfSage

2007-04-18 19:48

reporter   ~0013560

Your logic here baffles me Sts =)

Bricker

2007-04-18 22:40

reporter   ~0013570

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

stskeeps

2007-04-27 13:13

reporter   ~0013892

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.

vonitsanet

2007-04-27 13:28

reporter   ~0013893

when +L is active only allow +q to remove -l

stskeeps

2007-04-28 08:26

reporter   ~0013910

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

stskeeps

2007-05-04 08:36

reporter   ~0013998

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.

syzop

2011-07-19 14:08

administrator   ~0016704

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.

nenolod

2013-05-07 06:24

reporter   ~0017517

I decoupled this a while ago.

Issue History

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 stskeeps 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 stskeeps Relationship added has duplicate 0003240
2007-04-18 04:59 stskeeps Note Added: 0013501
2007-04-18 04:59 stskeeps 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 stskeeps Note Added: 0013892
2007-04-27 13:28 vonitsanet Note Added: 0013893
2007-04-28 08:26 stskeeps Note Added: 0013910
2007-05-04 08:36 stskeeps Status acknowledged => resolved
2007-05-04 08:36 stskeeps Fixed in Version => 3.3-alpha0
2007-05-04 08:36 stskeeps Resolution open => fixed
2007-05-04 08:36 stskeeps Assigned To => stskeeps
2007-05-04 08:36 stskeeps 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 nenolod Note Added: 0017517
2013-05-07 06:24 nenolod Status needs re porting => resolved
2013-05-07 06:24 nenolod Fixed in Version 3.3-alpha0 => 3.4-alpha1
2013-05-07 06:24 nenolod Assigned To => nenolod