View Issue Details

IDProjectCategoryView StatusLast Update
0002044unrealircdpublic2005-01-29 13:00
ReportermediceAssigned Tocodemastr 
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
Product Version 
Target VersionFixed in Version3.2.3 
Summary0002044: Implementation of Invex (chanmode +I)
DescriptionI didn't find any record with this - so I hope that I've nothing overseen...

well - I really like these to modes I've seen on other ircds:

+I -invite exception - works similar to +e - working on +i instead on +b-situations

+B -banlink - works similar to +L and joins users to a different channel - usefull if a community which wants to establish some kind of special channel in dealing with bans
TagsNo tags attached.
3rd party modules

Relationships

has duplicate 0002273 closed +e exempts +i as well 

Activities

codemastr

2004-08-27 21:04

reporter   ~0007440

Well that +B isn't going to happen. That would be a horrible idea. So you flood, and I kick you... now you automatically join another channel so that you can flood it? 500 clones join my channel, I ban them, now they automatically join another channel? That's horrible!

As for +I, I have nothing against it, but can you provide situations where it is really necessary? What I mean is, it overrides +i... Well why use +i? If you set +b *@*, no one can join. If you /invite a +b'ed user, they can join. And if they are on the +e list, they can join. So why not just set +b *@* instead of +i and get the same effect?

medice

2004-08-27 21:38

reporter   ~0007441

well - +I may be used as a permanent /invite in some kind - chan-ops may be set +I to be able to join in case there is a +i during an attack for example (i've never seen anyone set +b *!*@* , although it makes the same...)
or the owner may usually not be able to join because for some reason there has a +k been set
so the users need not to twiggle around with services (if there are any) or start to look who's online at that moment and communicate with than

there might not be a severe necessarity in this case - but it's a nice feature and since unreal has already many nice feature it will perfectly fit in, I believe.

for those who want to see +I in action - efnet has it.

yodaone

2004-08-28 05:15

reporter   ~0007442

If you set the channel +b *@* the users can't speak or change their nick, so +I would be nice.

aquanight

2004-08-28 05:44

reporter   ~0007443

Set services to autovoice everyone who joins?

But +e completely protects you from the effects of +b, so if you are +e'd so that you can join, then you can still talk/change nick.

As for +B, I have to agree with codemastr... though you could try coding an extended ban module to provide something like this, in which case you can select the banmask and the channel... like +b ~<whatever>:*!*@*.aol.com:#AOL or somesuch (IPv6 addys might create a problem with :. If so, use something like ; or TAB instead :P .) Shouldn't be too hard :/ .

medice

2004-08-28 08:23

reporter   ~0007445

Last edited: 2004-08-28 08:26

I always disliked the idea of autovoice for each and everyone - since a simple +m doesn't get the channel quite in case it's necessary...

i haven't thought on all the behaviour of +b before - so thanks yodaone :)
[edit] +e does protect form +b - but if you make +b *!*@* to lock a channel - every normal user in the channel is banned - which means no talk - no nickchange - so +i is the better solution to lock a channel temporarily [/edit]

+B isn't that important - was just a suggestion, in fact there is a +B-module going around, but it seems terribly broken (unreal does not start with module - rehashing module in after start seems to work - but that's nothing I'd dare to use...) and I'm no coder at all and have no time to learn C & Co from scratch ;)
but it's really not that important...

edited on: 2004-08-28 08:26

al5001

2004-08-29 17:23

reporter   ~0007453

The only difference between +iI and +be would be this:

Users:

Friend1!user@ca-BB178F31.wp.shawcable.net
Friend2!user@ca-DB598A58.wp.shawcable.net
Friend3!user@ca-8D76C321.wp.shawcable.net
BadGuy!user@ca-93C8F345.wp.shawcable.net

We want our channel #friends to be a private channel (only let friends in), and to keep BadGuy out of it.

#friends +iI *!*@*.wp.shawcable.net
#friends +b *!*@ca-93C8F345.wp.shawcable.net

Without +I, you'd have to do it this way:

#friends +b *@*
#friends +e *@ca-BB178F31.wp.shawcable.net
#friends +e *@ca-DB598A58.wp.shawcable.net
#friends +e *@ca-8D76C321.wp.shawcable.net

As this is a small example, in a larger channel, this would fill up the banlist and could possibly reach the exception ban limit.

Your proposed +B mode would just create a new tool for flooders to have fun on your server.

White_Magic

2004-09-04 16:28

reporter   ~0007518

maybe have a options in config, if u set +B to go to a certain channel - soon as they join the server bans them? - thus u ban something coz of bots flood they instaly go to that channel and they are K G or GZ`ed,

Thats the only thing i can see +B being usful for.

codemastr

2004-09-04 22:55

reporter   ~0007528

Well does anyone else have any opinions on +I? If I'm going to add something big like this, I'd kinda like to see more than just 1-2 users supporting it...

al5001

2004-09-05 00:36

reporter   ~0007531

Last edited: 2004-09-05 00:37

Well, as I was saying, there's really not much difference between using +be and using +iI. They'll still perform the same basic thing (with minor differences). I don't think +I is important, and I probably won't be using it -- so in other words, I'm not really supporting it.

Edit: Perhaps if someone really needs it, they could ask someone else to code a separate module to implement it.

edited on: 2004-09-05 00:37

aquanight

2004-09-05 00:42

reporter   ~0007532

Last edited: 2004-09-05 00:49

I am though :) . One thing that's going into WinSE is the ability to manage +e and +I lists via ChanServ in the same way one manages +b.

Without IRCd-side support for invex(+I), I'd have to resort to watching for knocks and autoinvite (and/or forcejoin) the appropriate users... (mind I'm not quite sure how I'd go about when an invite list entry is pushed into a channel... *poke @ w00t*

*edit*
>Edit: Perhaps if someone really needs it, they could ask someone else to code a separate module to implement it.

I don't know if that's possible. IIRC, Unreal internally handles I because mIRC would freeze if anything other than the "End of List" numeric was returned.

...codemastr beat me, didn't he? :P

edited on: 2004-09-05 00:49

codemastr

2004-09-05 00:48

reporter   ~0007533

al5001, well first off, a module can not do this, so that's already out of the question.

White_Magic

2004-09-05 04:08

reporter   ~0007535

We want our channel #friends to be a private channel (only let friends in), and to keep BadGuy out of it.

#friends +iI *!*@*.wp.shawcable.net
#friends +b *!*@ca-93C8F345.wp.shawcable.net

Without +I, you'd have to do it this way:

#friends +b *@*
#friends +e *@ca-BB178F31.wp.shawcable.net
#friends +e *@ca-DB598A58.wp.shawcable.net
#friends +e *@ca-8D76C321.wp.shawcable.net

whats wrong with +e *!*@*.wp.shawcable.net???

I dont support this either i cat see the point, unless +I was resevered for users with umode +r to use it it? *shrugs*

al5001

2004-09-05 19:31

reporter   ~0007543

whats wrong with +e *!*@*.wp.shawcable.net???


---> We don't want BadGuy!user@ca-93C8F345.wp.shawcable.net to join. Therefore, we ban *!*@* and channel except on all other hosts that should be allowed in (or you could ban *!*@*.wp.shawcable.net as well).

White_Magic

2004-09-06 09:59

reporter   ~0007557

Last edited: 2004-09-06 10:02

+I -invite exception - works similar to +e - working on +i instead on +b-situations

We want our channel #friends to be a private channel (only let friends in), and to keep BadGuy out of it.

#friends +iI *!*@*.wp.shawcable.net
#friends +b *!*@ca-93C8F345.wp.shawcable.net

-
Ok, So u ban the badguy IP but u have his ISP on +I - Invite overrides a ban... therefore ur not keeping him out the channel.... Oh and coz the channel is Already +i - it clearly shows that the badguy is allowed to use +I so this is usless far as i see

or am i missing something? coz thats what it looks like to me.

*edit to fill in +i / +I text*

edited on: 2004-09-06 10:02

aquanight

2004-09-06 14:38

reporter   ~0007558

IIRC, Invex doesn't quite work that way.

In other words, matching an invite mask isn't quite the same as being actually invited. Invexs are *inv*ite *ex*ceptions, which means matching people are allowed to walk +i (invite-only), but nothing else AFAIK.

codemastr

2004-09-06 16:28

reporter   ~0007559

[quote]matching an invite mask isn't quite the same as being actually invited. Invexs are *inv*ite *ex*ceptions, which means matching people are allowed to walk +i (invite-only), but nothing else AFAIK.[/quote]
Well, it's kinda hard to say. Hybrid, for example, doesn't let /invite override +b either! The only time Hybrid checks either the +I list or the /invite list is when the channel is +i. Bahamut is different though. In Bahamut, +I overrides everything *except* +b. I haven't tested yet, but it seems as though, even if the channel is +k, if you are +I'ed, then you can join. IRCNet seems to work like Hybrid. +I only overrides +i.

I'm not really sure which way is best, both have merit. For example, it would allow an op to get passed +l really easily. But, it also has bad points. Like if I set +I *@*.someisp.com, and my channel is +R, well now non-registered users from that ISP can come in, which probably is not what I wanted.

If anyone has suggestions on which way is better, I'm willing to listen.

aquanight

2004-09-06 16:39

reporter   ~0007560

Hm... well, some possibilites:

1 /invite works like it does now (overrides everything except +AO). +I list only
  overrides +i.
2 /invite works like it does now (overrides everything except +AO). +I list only
  overrides +ikl.
3 As #1, but ~R:mask entries override +R as well.
4 As #2, but ~R:mask entries override +R as well.
5 As #1, but ~o:mask ("operator") entries override +kl.
6 As #5, but said ~o:mask entries override everything except +AO like /invite
  does.

Combinations could get interesting, such as #3 and #5 combined could be useful...
Naturally, 3, 4, 5, and 6 would mean implementing the extended ban system on the +I list... but...

medice

2004-09-06 17:14

reporter   ~0007561

whatever comes: it should be clearly documented, what is overriden by +I...

as a mather of fact I'm not really sure what an /invite exactly overrides - so don't stone me right after (maybe an idea to document this?)

I think there are 2 points of views:
on one side: it's the user who has to make clever mode-settings (+I *!*@* - jippie ;) )

on the other side - what I personally think would be senseful...

generally spoken /invite overrides modes that block joining a channel - so I had a look on the modes which are actually blocking (hope didn't forget any)

A/O --> nothing I'd like to be overriden by /invite nor +I
z --> same - it would allow matching non-sslers to join
R --> as mentioned - no - it would allow unregistered users in which brakes the idea of +R
b --> difficult decision - there is +e, but why not - I'm honestly not quite sure...
i --> well thats where the whole thing started --> yes!
k --> +k provides a similarity to +i, in my opinion, on a "close the channel down"-point of view it's weaker than +i since the key may be told around anywhere - so yes
l --> yes (but I'm personnally not really using +l often and have not many experiences... many channels I've seen just set +l to have a cool mode-look +l 1337 ... whatever they want...)


is it really necessary to implement the extended ban-system in +I?
it's a fine idea, so you may define severyl extensions with special mode-overrides, but I think this is a heavy to complex thing and don't know if it brakes clients?

White_Magic

2004-09-06 19:40

reporter   ~0007563

Thanks for explaining that aqua :)

my thoughts are +I should override +il only -

The reason against k is it could allow a user to " fix " the channel and make it open to floods / bots - but not only against them any unwated guests.

modes - R z b A O need to keep their purpose, should someone crack a channel key in any chance at least they can still set +R to stop <whatever> entering. or even use +z to stop them...

codemastr is defently mode +B out - even thou i suggested a possible use for it?

codemastr

2004-09-06 20:07

reporter   ~0007564

Last edited: 2004-09-06 20:07

[quote]is it really necessary to implement the extended ban-system in +I?[/quote]If I did add extban support to +I, it wouldn't be like was suggested. It would work just like the current system, e.g., +I ~r:*blah* adds an invite for someone with a realname matching that. If we did it any other way, it would just lead to confusion.

[quote]The reason against k is it could allow a user to " fix " the channel and make it open to floods / bots - but not only against them any unwated guests[/quote]
Can you explain this? I don't understand what "fix the channel" means at all. And I don't see how this makes it open to floods? As medice kind of mentioned, +k isn't a good flood stopper because if the key is discovered, then the bots can join. How does +I make the situation any worse?

[quote]codemastr is defently mode +B out - even thou i suggested a possible use for it?[/quote]
Your use made no sense to me. You said that you would set them +b, then have them redirected to #somechan where they are akilled... Well why bother setting them +b to begin with? Why not just akill them immediately? That doesn't make sense to me. All it does is redirect them to another channel where they will continue to flood until they are akilled, and if services are down and the akill is not automatically added, well now they just keep on flooding. And if you really wanted it, that could be done with a module.

edited on: 2004-09-06 20:07

aquanight

2004-09-06 22:17

reporter   ~0007567

Well, some of the extended ban stuff doesn't quite work very well with Invex... for example, ~q and ~n have no meaning with invex.

Granted this would be simple to integrate by just passing the BANCHK_JOIN to the check routines, and the EXBTYPE_EXCEPT (or a new constant) for the (un)set routines...

White_Magic

2004-09-07 16:23

reporter   ~0007575

Can you explain this? I don't understand what "fix the channel" means at all. And I don't see how this makes it open to floods? As medice kind of mentioned, +k isn't a good flood stopper because if the key is discovered, then the bots can join. How does +I make the situation any worse?

" Fix the channel " i mean to set it up so it can be exposed / attacked.
Invite could override +k so they could add the bots to +I which would allow them to flood, and maybe the channel ops wouldnt know why they can keep coming in *even thou +i is on they are still joining* - this is how i see it as worse.

aquanight

2004-09-07 16:27

reporter   ~0007576

Last edited: 2004-09-07 16:29

>" Fix the channel " i mean to set it up so it can be exposed / attacked.
>Invite could override +k so they could add the bots to +I which would allow them
>to flood, and maybe the channel ops wouldnt know why they can keep coming in
>*even thou +i is on they are still joining* - this is how i see it as worse.

Uhhhh Only a _Channel Operator's_ Invite will override +bikl. If an Operator adds floodbots/etc to the +I list, then he should be subject to punishment by the other channel staff.

*edit* (blah, how did you get those funny quote:| thingies? :\) */edit*

edited on: 2004-09-07 16:29

codemastr

2004-09-07 19:26

reporter   ~0007578

[quote]and maybe the channel ops wouldnt know why they can keep coming in *even thou +i is on they are still joining* - this is how i see it as worse.[/quote]
If the channel ops don't know what +I is, why did they set it?

[quote]*edit* (blah, how did you get those funny quote:| thingies? :\) */edit*[/quote]
I got tired of typing out ">" at the beginning so I added support for the bbcode [quote] tag. At the end you also need a [/ quote] (without the space) to tell it where the quote ends.

aquanight

2004-09-07 19:30

reporter   ~0007579

[quote]If the channel ops don't know what +I is, why did they set it?[/quote]

Of course... this is one of this cases where using SVSMODE to clear a channel list (namely +beI) could be useful for a normal user... :)

syzop

2004-09-07 20:32

administrator   ~0007582

I prefer ircnet/hybrid's way.. +I only affecting +i.

In practical situations I've experienced that +l(/+k) overriding can be quite helpful too. I'm however against making +I affect any other chanmode than +i/+l/+k (such as +b)... that would be very confusing.
In fact, I'm not sure at all whether +I should affect +ilk or only +i... Because if it affects +l it can be very confusing...
'*** Alpha sets mode: +l 0
*** Beta has joined #test
<Alpha> Hi Beta. Uhm.. how did you join?
<Beta> I'm on the invite exception list
<Alpha> But the channel is not invite only
<Beta> Yeah, well...'
I also thought of other ideas like making it only override +l/+k when +i is set AND +l or +k, but that makes it only MORE confusing IMO.
Seeing as how there are currently 2 variations around...
ircnet, hybrid: +I overriding +i
bahamut: +I overriding all chanmodes (even +O) except +b
I'm not sure if adding yet another variation (eg +I affecting +i/+l/+k) is a good idea. It should be clear at least, that the practical advantages of +lk overriding should outweight the confusion it adds.

@extban alike stuff..
I'm not too keen on that for +I.. both me & codemastr are not 100% convinced that +I is so very useful, so I don't think anyone of us is really willing to make it so complex/put so much time/effort in it.

aquanight

2004-09-08 03:20

reporter   ~0007586

Yes... definately no +b overriding... that's what +e is for :P .

[quote]bahamut: +I overriding all chanmodes (even +O) except +b[/quote]
AFAIK, the only modes that block joins are +iklRO. I really don't think a nonoper should be allowed to join an oper-only channel by any means short of /sajoin :P (and probably not even that...). So that leaves +iklR. I like to think of +R as a form of +i, not really different. Though +R is intended to keep out unregistered users, it's mostly used as flood control / anti-spambot. I could tell users to register and identify, but how would I do so? I only have the topic visible to outsiders, and I might have +s'd my channel to help turn away yet more spambots... and of course, they can't /knock because the channel is not +i... so all they can do is pray I'm online and PM me... or of course take the initiative and register their nicks, but then there's the possibilty of services downtime (mind: in the real world, I'd probably -R and use something else if services go down - having NickServ in the notify list helps :D !).

But of course you can think of this: INVEX is INVite EXception. Matching users are exempt from /invite requirements. The only the mode that imposes an invite requirement is +i. +bkl simply have invite as an override. Someone trusted with an INVEX should probably also have the channel key, and probably can just wait until the channel membership decreases or the limit is increased. Or they can /chanserv INVITE :-) .

If you ask me, I'd say utilize the extban system so that the choice can be left to channel operators.

White_Magic

2004-09-08 12:12

reporter   ~0007587

Last edited: 2004-09-08 12:14

Um 1 question...


'*** Alpha sets mode: +l 0
*** Beta has joined #test
<Alpha> Hi Beta. Uhm.. how did you join?
<Beta> I'm on the invite exception list
<Alpha> But the channel is not invite only
<Beta> Yeah, well...'


um if Alpha had set a +L - im presumming they would go to the other channel right?

i also agree with syzop, the only modes i should see it affect are +il.

edited on: 2004-09-08 12:12

edited on: 2004-09-08 12:14

codemastr

2004-09-08 17:43

reporter   ~0007592

[quote]um if Alpha had set a +L - im presumming they would go to the other channel right?[/quote]
Yeah, +L is where +l gets even more tricky. Because imho, if we say "+I overrides +l" but "+I does not override +lL" that makes things even more confusing! :P So I'm kinda leaning towards just +I overrides +i. It seems everything else is going to lead to some kind of confusion.

aquanight

2004-09-08 17:51

reporter   ~0007593

Yeah. It probably wouldn't be to hard for services to provide a form of override for other modes if it was wanted... like check if the channel is +l, the user has some ChanServ privilege to override the limit, he can just ask ChanServ to let him in (which can of course include either raising/removing the limit or simply inviting the requester)...

syzop

2004-09-09 00:36

administrator   ~0007596

aquanight: well, yes.. authorized users can just /CS INVITE themselves.. this has existed for years and it's a nice feature (eg: for bots) since it goes trough a lot of modes ;p.


Anyway, good! Then we hereby decide that +I only overrides +i! :P

aquanight

2004-09-09 05:21

reporter   ~0007598

syzop: I wasn't referring specifically to /cs invite. There could be restricted versions that any one can use but have a few conditions, like match a +I and only +l is set (nothing else, like +kAOzb - unless of course the user meets the necessary conditions (knows the key, is an admin/oper/ssler, or matches a +e :P )) and user is on the access list or something like that and the channel isn't over the limit by a significant amount, or something along those lines... but yeah INVITE works too :) .

Stealth

2004-09-21 17:19

reporter   ~0007753

I would also like to see +I implemented. It seems it can be a useful feature in private channels where only certain users are allowed to join.

With current invites, you need to invite every user every time he/she connects. With +I that user stayes on the invite list, and there is no re-inviting needed.

Lynxer

2004-12-03 05:41

reporter   ~0008463

Our network needs +I or something similar to it. There is a student hostel connected to our network, and they want to keep their channel private, i.e. only students can join. Early they used hybrid ircd and &channel. Now they reject to migrate to unrealircd for this reason. They say +I would be fine, but unrealircd doesn't support it. :( +e is not solution for them, because channel ops sometimes have to ban some students when they talk badly or otherwise break channel rules. This userbase is quite big and we don't want to loose them. Please implement +I. Another solution might be to implement "inverted" or "non-match" bans. That is, mode like "+b ~i:*!*@*.hostel.net" means that everyone that does not match "*!*@*.hostel.net" is banned. But it's unclear what to do with multiple such bans. So +I is better in my opinion.

syzop

2004-12-03 11:09

administrator   ~0008464

don't worry, +I is scheduled for Unreal3.2.3 :P.

aquanight

2004-12-03 11:58

reporter   ~0008468

Also, the "inverse ban" idea could easily be done in a module.

Stealth

2004-12-03 18:23

reporter   ~0008478

"Inverse ban" is the same thing as:

mode #channel +be *!*@* *!*@*.hostel.net

I dont see a need for another extended bantype for something so easily done otherwise.

aquanight

2004-12-04 02:52

reporter   ~0008479

Well what happens if you want to ban *!*@user-7F000001.hostel.net ? But like I said, it'd be like supereasy to do that in a module so blah :P .

pepolez

2004-12-04 23:07

reporter   ~0008497

*Quote: medice *
l --> yes (but I'm personnally not really using +l often and have not many experiences... many channels I've seen just set +l to have a cool mode-look +l 1337 ... whatever they want...)
*End Quote*
+l (channel limit) is often set between 1 and 3 higher then the current user count so for example, if 100 floodbots try to join at the same time, only 1-3 will get in (depending on the user count/channel limit ratio). This mode is more useful then it often seems.

Unfortunately, the floodbots can still probably get in (slowly) as the bot/script gradually sets the channel limit higher and higher as the floodbots join. But this is a problem for bot developers and irc client scripters, which can easily be worked around, and has been on most bots by setting +ikm when there is a join flood, even if all of the hosts are different.

In conclusion, I'd have to say that +l is important to avoid channel floods.

codemastr

2005-01-29 12:19

reporter   ~0008938

+I is added in .240

Issue History

Date Modified Username Field Change
2004-08-27 20:55 medice New Issue
2004-08-27 21:04 codemastr Note Added: 0007440
2004-08-27 21:38 medice Note Added: 0007441
2004-08-28 05:15 yodaone Note Added: 0007442
2004-08-28 05:44 aquanight Note Added: 0007443
2004-08-28 08:23 medice Note Added: 0007445
2004-08-28 08:26 medice Note Edited: 0007445
2004-08-29 17:23 al5001 Note Added: 0007453
2004-09-04 16:28 White_Magic Note Added: 0007518
2004-09-04 22:55 codemastr Note Added: 0007528
2004-09-05 00:36 al5001 Note Added: 0007531
2004-09-05 00:37 al5001 Note Edited: 0007531
2004-09-05 00:42 aquanight Note Added: 0007532
2004-09-05 00:48 codemastr Note Added: 0007533
2004-09-05 00:49 aquanight Note Edited: 0007532
2004-09-05 04:08 White_Magic Note Added: 0007535
2004-09-05 19:31 al5001 Note Added: 0007543
2004-09-06 09:59 White_Magic Note Added: 0007557
2004-09-06 10:02 White_Magic Note Edited: 0007557
2004-09-06 14:38 aquanight Note Added: 0007558
2004-09-06 16:28 codemastr Note Added: 0007559
2004-09-06 16:39 aquanight Note Added: 0007560
2004-09-06 17:14 medice Note Added: 0007561
2004-09-06 19:40 White_Magic Note Added: 0007563
2004-09-06 20:07 codemastr Note Added: 0007564
2004-09-06 20:07 codemastr Note Edited: 0007564
2004-09-06 22:17 aquanight Note Added: 0007567
2004-09-07 16:23 White_Magic Note Added: 0007575
2004-09-07 16:27 aquanight Note Added: 0007576
2004-09-07 16:29 aquanight Note Edited: 0007576
2004-09-07 19:26 codemastr Note Added: 0007578
2004-09-07 19:30 aquanight Note Added: 0007579
2004-09-07 20:32 syzop Note Added: 0007582
2004-09-08 03:20 aquanight Note Added: 0007586
2004-09-08 12:12 White_Magic Note Added: 0007587
2004-09-08 12:12 White_Magic Note Edited: 0007587
2004-09-08 12:14 White_Magic Note Edited: 0007587
2004-09-08 17:43 codemastr Note Added: 0007592
2004-09-08 17:51 aquanight Note Added: 0007593
2004-09-09 00:36 syzop Note Added: 0007596
2004-09-09 05:21 aquanight Note Added: 0007598
2004-09-21 17:19 Stealth Note Added: 0007753
2004-12-03 05:41 Lynxer Note Added: 0008463
2004-12-03 11:09 syzop Note Added: 0008464
2004-12-03 11:12 syzop Status new => confirmed
2004-12-03 11:58 aquanight Note Added: 0008468
2004-12-03 18:23 Stealth Note Added: 0008478
2004-12-04 02:52 aquanight Note Added: 0008479
2004-12-04 23:07 pepolez Note Added: 0008497
2005-01-11 15:54 codemastr Relationship added has duplicate 0002273
2005-01-29 12:13 codemastr Summary Implementation of Invex (chanmode +I) and Banlink (chanmode +B) => Implementation of Invex (chanmode +I)
2005-01-29 12:19 codemastr Status confirmed => resolved
2005-01-29 12:19 codemastr Resolution open => fixed
2005-01-29 12:19 codemastr Assigned To => codemastr
2005-01-29 12:19 codemastr Note Added: 0008938
2005-01-29 13:00 codemastr Fixed in Version => 3.2.3