View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000606 | unreal | ircd | public | 2003-01-07 23:08 | 2007-04-16 09:59 |
| Reporter | armed_armadillo | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| OS | FreeBSD | OS Version | 4.7 | ||
| Product Version | 3.2-beta14 | ||||
| Summary | 0000606: Setting more than one channel mode (o, h and v) on a user can desync these modes with client | ||||
| Description | A channel op (or halfop) can set halfop or voice on themself. When a op (or halfop) has more than one channel mode set on them, a /who will only reveal the highest of @, %, or + for this user. Also, if a new user than joins the channel and the op deops themselves, the user will not see that the former op is still a halfop or voice, as the client has no way of being updated about the "hidden" mode (although a /names will resync the client). Relatively trivial, but I thought I would report it anyway. | ||||
| Steps To Reproduce | Join a channel where you have op status (client A). Now halfop yourself (if you do a /who on yourself at this point, you will only see @, not @%). In a seperate client (client B), join the channel. Now deop yourself on client A. Client B will see Client A as a regular channel user, when in reality Client A is still a halfop. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| has duplicate | 0002167 | closed | Possible channel mode +qaohv desynch | |
| has duplicate | 0002170 | closed | an old bug.... | |
| has duplicate | 0002346 | closed | When +a goes -a and then try +o you have to -o first | |
| has duplicate | 0002948 | closed | Not showing voice modes of the users currently op-ed on the channel, OnJoin. | |
| related to | 0002833 | resolved | UHNAMES (and NAMESX too) |
|
|
This bug is very similar to the problem that my friend experienced one year before on coding his own irc client program. The problem is totally the same. It seemed as a client bug. I'm very excited about what the coders think of it. |
|
|
This has NOT GOT THE LEAST to do with the IRC daemon. If client coders are too stupid to code RFC conformant clients, then they should not code their 1337 irc t00lz in things regarding halfop: this is generally pretty unrfcish too .. dont wonder about clients breaking support there ... edited on: 01-08 16:46 |
|
|
I meant Unreal coders. And you are speaking about client coders very furiously. Please, don't do that, at least, not here. This site is a bugtracker, not a discussion forum. |
|
|
This bug affects every client with a nick list (that I have tested) including mIRC, KSirc, and Leafchat. The problem is not in the client, because the client has no way of being informed about the change. The RFC has no documentation on how to handle this behavior (probably because given the current protocol it is impossible to correctly handle this behavior), so it is undefined. IRCu and Bahamut will not let you set both channel op and voice on the same user, preventing this issue altogether, and perhaps that would be a good idea for Unreal also. |
|
|
This is an interesting situation. The RFCs (1459 and 2812) state that only an @ or a + (but not both) may be sent in a RPL_WHOREPLY or RPL_NAMREPLY. We can take a liberty of including a % here (and hope the client coders implement support) because it really doesn't violate the protocol too much. However, we can't pass all of a users modes (like @%+nick in a RPL_NAMREPLY) because this would most likely cause clients to take the first character as a mode character and the rest of them as part of the nickname. So it seems to me that we are left with three possible solutions: the first is what armed_armadillo said, don't allow multiple modes to be set in the first place. The second is to leave everything as it is and force client coders (and scripters for that matter) to do a /names or a /who whenever they see a mode change. The third is for unreal to asynchronously send a RPL_NAMREPLY when such a mode change occurs. This of course could break some clients that are not expecting such a message because they didn't ask for it but I tend to think that it may just work. What are your thoughts? |
|
|
Another but obviously impossible solution: modifying irc protocol. :) RFC 1459 is definitely old, and it would be very nice if "q" and "a" modes could have their own symbol, like "o", "h", "v". But to do such a modification, a lot of client coders have to make their programs compatible with this as quickly as possible. I don't think forcing a /NAMES would be the perfect solution, so I'm voting for the first one. módosÃtva ekkor: 01-09 09:11 |
|
|
I agree with {AngryWolf} for the additional chars for owner (at least, more if needed). And a precision, the Half-Op (+h/'%') isn't from RFC, so the obvious solution is already used... As I know, X-Chat uses the char '*' to identify admins (coming from ircu ?) that should give a red point before the nick... so to my mind implementing extra things that users want won't be a problem for coders. And I also vote for the first solution given by mcskaf, because just thinking to people playing with their modes, mass moding others and so on... and receiving 2 messages just for a -o, multiplied by how many people are -oed... a bandwith waste... |
|
|
mm this problem has always existed. I've been (a)busing it at IRCNet X years ago. also weird irc servers lke IRCX (m$) for example do -o if you +q (own) a user, but don't do -v if you +o, so the v/o problem still exists. "The best solution" is to drop other modes like someone pointed out... if you +o then do a -v (if it was there), however I'm not sure if that's possible with our current mode system coding style ;P. Bandwith waste? yes. Is it worth it? I don't know, personally I don't care much :P. |
|
|
Well there is a solution to this issue, and I think I'm going to do it, to really fix it it will take participation on the part of client coders, but it will still be fully backwards compatible. It goes like this: In the 005 numeric we send a NAMESX token, if the client supports this it sends back: PROTOCTL NAMESX this informs the server that it is safe to include a string like @%+nick in a NAMES reply, if the client doesn't support NAMESX it simply continues to work as usual. |
|
|
just wondering how is the work for this point ? |
|
|
I'm also curious for the answer of this question, but ... well, codemastr has a lot of things on his todo list (http://devel.unrealircd.com/~codemastr/TODO), so I don't think it will be ready soon. :) By the way.. I can't see this feature on his todo list, do you? :-) |
|
|
Severity "trivial" (lol :P) -> "feature". As codemastr explained this requires changes to both clients and servers, so think in terms of months.. not weeks... |
|
|
as I saw in xchat 1.8.x sources, this has already been (at least partly) implemented... |
|
|
I'ld like to know where is it and if it works because i use xchat 1.9.8 |
|
|
dunno if it works (should have a server with this kind of think implemented... and I don't know any) but you can find this (what I think is) in src/common/userlist.c in fonction add_name( ) - line 340 (well line 329 for the 1.9.x serie) /* most ircds don't support multiple modechars infront of the nickname for /NAMES - though they should. */ while (prefix_chars) { update_counts (sess, user, name[0], TRUE, 1); name++; prefix_chars--; } I may be wrong, but for me prefix_chars is the number of prefix before the nick, and to add the nick this loop simply removes the prefix from the name (result of the NAMES commandes) to have only the nick in the userlist edited on: 02-12 10:46 |
|
|
Now the problem expands to the new prefixes, too (+a/+q). Can I ask what about the NAMESX token and if it will be supported by any client programs? |
|
|
Maybe server can set/send "hidden" modes at join, then the problem is moved to irc client(By sending a MODE command to the new client after NAMES)? |
|
|
no |
|
|
Mh, will this NAMESX token now be added? mIRC don't support that in the new version 6.12, but it never got requested I think. But it only make sense to request that on there forum, when it will be added on unreal too ;) Or do the client coder of mIRC already now that? ;P |
|
|
I presume this will be added within a month in UnrealIRCd. One of the reasons it got delayed is that ircd coders seem to disagree how a client should mention his 'options' to the ircd. We use PROTOCTL, the bahamut people want their idiotic CAP idea, and other ircd coders find CAP totally stupid but didn't come up with an alternative. So I think we should just implement this via PROTOCTL, we could add support for other crazy ideas later (then it's just setting a flag). |
|
|
The reason I haven't added it to Unreal is simple, I was told by most of the major IRC client coders that they'd only support it if it were added to some other "major" IRCds. I talked with the ircu and the hybrid coders. They both said it was a nice idea, but none actually committed to adding it. I don't personally have a problem with adding it to Unreal, the only thing is, it won't actually solve anything unless the clients support it. On a side note, what Syzop mentioned about CAP is no longer relevant since the internet-draft describing that command has expired so it is no longer a valid option. The real problem comes in with PROTOCTL (The "dreamforge" method) and CAPAB (The "hybrid" method). Or, for that matter, should an entirely new command be developed for this purpose? |
|
|
Well, you had the Idea with NAMESX. But I can understand the problem ;) |
|
|
Maybe a new command. The name doesn't matter much to me, but I like the current simple 005-alike way of PROTOCTL (dunnow if CAPAB works just like that?).. simply a list of things you support space-seperated, in contrast to the CAP idea (a la telnet) which causes a flood of 4793263 lines. **edit** I can understand they wanted to go very advanced in CAP (like pre-auth handshake and back-confirm [whether an option was acknowledged or negative ack], etc) but it was a bit overkill IMO, I think history has proven that simple things have a much higher success rate :p. edited on: 10-30-03 22:44 |
|
|
Yeah CAPAB works like PROTOCTL. The only reason I personally think using PROTOCTL is better than CAPAB is because CR already uses PROTOCTL to negotiate client features. While I'm not the biggest fan of CR, it seems like using a mechanism that is already in place is the best way to go. CAP had some nice ideas, but overall it was bad. If I were to implement an ACK/NAK system for IRC it would be much more simplistic: Server sends: 005 NAMESX SOMETHINGELSE Client sends: PROTOCTL NAMESX SOMETHINGELSE SOMEOTHERTHING Server sends: 006 +NAMESX +SOMETHINGELSE -SOMEOTHERTHING That way the ACK/NAK is handled in one command (ok maybe 2 if it exceeds 16 params), and it pretty much does what it needs to. But, imho we could do some crazy stuff with a client based response to 005 (and validation). Consider this, we add +aq prefixes, some clients won't support them; no problem! Server sends: 005 PREFIX=(qaohv)~&@%+ Client sends: PROTOCTL PREFIX=(ohv)@%+ Server sends: 006 +PREFIX=(ohv)@%+ And then, for that client, +qa prefixes are not displayed since it specifically told the server that it doesn't understand them. (Oh and of course 006 was just an arbitrary number, that could very well be in use already). |
|
|
Oh one other thing. There is a flaw with using 005/PROTOCTL that something like CAP would stop. What if 005 has NAMESX, client sends PROTOCTL NAMESX, but, the server has an auto-join-chan so the user is forced there. That would occur before the PROTOCTL NAMESX is processed and therefore only single prefixes would be used for the auto-join channels. The only way I can see to avoid that is with a pre-registration negotiation... |
|
|
yeah auto-join would be a problem (well the client can send the PROTOCTL before he's registered but then he hasn't received the 005 info so that's prolly not a good solution ;p)... The 006 alike thing is good I guess, although I never understood the need for NACK, because.. when the server announces it, the feature should be available and if he doesn't announce a feature it isn't... so I don't see where NACK would kick in, but I guess adding it would be a good idea anyway in case I/we missed something ;). Oh about your PREFIX= example I think that would cause problems with the +qo/-q/-o stuff but I get the idea :p. Now back to pre-auth.. this would make it a lot more complicated, something I wanted to avoid (it's getting pretty close to CAP this way), but.. you are right about auto-join and I don't see another solution to that. Also, in the future maybe charset selection would go via this (???) and then it's prolly a good idea to do in a very early stage (like pre-auth) too. However, things like this would make it very CAP-alike... C->S: PROTOCTL HANDSHAKE announces that the client supports it, note that 'PROTOCOTL BLAH' here won't a handshake but we will accept the options directly (and send a numericY??.. blah.. details..) C->S: NICK fdsfsdsfd C->S: USER blah blah blah blah S->C: [numericX? cmd?] OPTION1 OPTION2 OPTION3=blah OPTION4 OPTION5 OPTION6 OPTION7 S->C: [numericX? cmd?] OPTION8 OPTION9 END note that END means the server has finished sending his 005(-alike) stuff. C->S: PROTOCTL OPTION1 OPTION2 OPTION3=blah OPTION8 END and here the END means the client has finished sending his confirmation S->C: [numericY? cmd2?] +OPTION1 +OPTION2 +OPTION3=blah +OPTION8 END maybe END is not needed here. S->C: :serv 001 nick welcome..... Another idea (probably stupid, but I'm mentioning it anyway) is to make numericX a new numeric and make numericY = 005 as a confirmation but then you loose NACK. One thing I'm worried about is that this system will conflict/get desynched with 005 because you got 2 systems next to each other... something we have to think about too. Also, note that in this example there's no way to request a new option after a NACK, so what use is the NACK then :p. I guess the question is how flexible (and thus complicated) we want this to be. |
|
|
Example why NACK might not be needed even in multiple-options situations: -- charset selection could go like this PROTOCTL CHARSET=chinesebla,utfbla,ascii just like with HTTP (Accept-Language: en-us,en,nl,fr,de) it will step trough the list and the 1st one that is available "wins". and then the server would reply back just like with any option somenumeric OPTION1 OPTION2 CHARSET=the_one_that_won OPTION4 OPTION5 .. (note that this is just an example, I'm not thinking about implementing charset stuff at all :p) and even if we need explicit NACK we could just change 005/numericY and add prefix it with a -, older clients will just ignore the option.. newer clients will know what it means. Ah well... maybe it's better to move this to mail or irc :)). |
|
|
This is a very interesting issue - I see two or three solutions The one I like the best is the NAMESX option you spoke about earlier, in which multiple modes are given in the NAMES reply But here's another thought: Let's say a client has +o and +v in a channel, then he -o himself. Make server send not just :nick MODE #channel -o nick But instead: :nick MODE #channel -o+v nick nick Or another idea, when other users join the chan, and the server sends the new user the NAMES command with @nick, have the server then send the user an additional message: :nick MODE #channel +v nick to make the client sync that way no desync can occur. Like I said, I still prefer the NAMESX idea, but this might be an option too........ - fez edited on: 10-31-03 22:07 |
|
|
fez: yes, see my first reply... anyway, we are thinking about insane handshake protocol ideas atm :p. |
|
|
IMO the PROTOCTL HANDSHAKE idea is the best one, so even non-l33t clients can handle multiple modes names giving a command will just result in having ircops and some people using it, due to the fact that 90% of irc users don't care at all about such a thing... I tested it, in a modified unrealircd (based on 3.1.6), I simply added a XNAMES command that allow people the use or not the extended names reply you can test it at irc.chat-libre.net:6667 (in the 005 there is a XNAMES=0/1/2 option, in which the number means: 0=XNAMES is disabled / 1=client should enter "/XNAMES <0/1>" to deactivate/activate it / 2=XNAMES is forced, so everyone will receive extended names reply) this has been tested with some irc clients, and as I said in a previous note, xChat can handle this thing perfectly, for 1.8 and 2.0 series, and even mirc 6.1 has been tested ok with it. I didn't try BitchX, but kSirc and kVirc (2.x.-i don't remember exactly) are not compatable (kSirc doesn't take any mode at all, kVirc just remove the first one) |
|
|
well I agree to say that modifying the PROTOCTL will give a better interactivity between server and clients and more access for future use to developers ideas, but for this particular problem, and some others of the same kind, why not simply use the unused field of the USER message ? the third field is free for client->server communication, it can be used so to give the server any additional information on the client ([stupid] even things like gender, age, drink beer, is gay or whatever... don't care [/stupid]) all that by some numeric flags or things like that (to bypass some clients who may send something in this field) it's more RFC-compliant and really less job... for ircd and client coders |
|
|
It's not more RFC compliant, in fact it breaks RFC1459. In the event of creating a new message, you can define it yourself. However, you are saying we should ignore what RFC1459 says about USER and use it for our own purposes. How exactly is that a good thing? |
|
|
yeah, my error... I had rfc2812 in mind instead of 1459... I won't delete my previous note but people can easily ignore it... anyway, don't you think (you, who read, not only the coders) that it is growing to something a little bit too much for what it is intended for ? first a command (that I know is not the good solution, until the client do it by itself...), then a 005 option, and finally a revamping of the client connection protocol... will other coders (ircd & clients) follow that ? this is really a good idea to implement a interactivity between server and clients, but I think this should have a real interest, not only to show people that toto still has a + when he -o himself I hope somebody got an idea on something that can be used with this solution ** edit ** to explain myself: even if I think that syzop's idea is good, even better than the rest, to my mind this kind of 'bug' can easily be resolved by the client sending a string saying it can use the "extended names format", like a command at connection (NAMESX, or XNAMES as I did...) or a usermode (like +X) that will be treaten internally by the server and won't appear in the client's usermode string, or a PROTOCTL NAMESX, or ... whatever the used solution is, a simple string from client to server (in server's code, it adds a bit in the user struct and a comparison in names reply code) is enough for this case and others of the same type servers that don't use the specified extension would just ignore it, or at best answer that they don't know this command, or this usermode, and will continue to answer the normal names reply and for servers that can use extended names reply, if the client doesn't specify anything, then they will follow the normal way edited on: 11-04-03 13:15 |
|
|
That may very well be the way IRCX does it, but it's not the way IRC does it, and it's not the way Unreal is going to do it. The way Unreal will solve this problem is by a draft I am currently authoring to expand the IRC protocol to allow negotiation between the client and server. http://www.codemastr.com/draft-meglio-irc-handshake-00.txt |
|
|
I know this issue has been thoroghly discussed, and I wouldnt bring it back, but I had an idea for a simple solution. Unreal can use send the NAMESX in the 005 numeric, and people with clients that support NAMESX can simply have their client send back "protoctl NAMESX" on connect. This will allow the clients that can use NAMESX to use it, without affecting anyone who uses a client that does not support it. This will be a good solution for now, and when client/ircd coders decide to add it to the clients/ircds, it will go smoothly. |
|
|
Yeah I've thought of that. But, for example, it would not work with set::auto-join ;) Add to that that it isn't going to be a real standard and that I doubt client coders would be really using it.. that makes you wonder if it's worth it. Oh and, I think it also kinda undermines standard attempts like the one we are working on. So.. most likely it won't happen ;) |
|
|
Well, it was a thought. I for one wouldn't mind seeing something like it even as something the client needs to request. You do have a good point though. |
|
|
A simple solution for this something like this: 1) I Joined To MY Channel... 2)*** ChanServ sets mode: +qaohv Me ------------------------------------ 3)*** Me sets mode: -q Me THEN: *** SERVER sets mode: +aohv Me 4) *** Me sets mode -a Me THEN: *** SERVER sets mode: +ohv Me 5) *** Me sets mode -o Me THEN: *** SERVER sets mode: +hv Me 6) *** Me sets mode -h Me THEN: *** SERVER sets mode: +v Me And thats the end of the story:P |
|
|
If /names sends ~&%nickname (for example), other users will see & or % if ~ is removed. Obviously, his compatibility depends of clients. I know that mIRC, xchat and bitch supports this. For Kvirc 3.0.0.2beta there is a patch in http://www.irc-dev.net/descargas/kvirc.patch to resolve it. |
|
|
[quote]If /names sends ~&%nickname (for example), other users will see & or % if ~ is removed. Obviously, his compatibility depends of clients. I know that mIRC, xchat and bitch supports this.[/quote] That's 3 clients out of about 120 that I know of. That's not nearly enough for me to add this feature. Hence why the NAMESX protocol idea is necessary. |
|
|
[quote]That's 3 clients out of about 120 that I know of. That's not nearly enough for me to add this feature.[/quote] So, how many clients support NAMESX? Moreover, how many clients support PROTOCTL? |
|
|
[quote]So, how many clients support NAMESX? Moreover, how many clients support PROTOCTL?[/quote] That's completely and totally irrelevant. The point is, my solution won't BREAK clients. Yours will. Any client that doesn't support NAMESX will still work 100% fine. With your solution, they won't. I will *not* implement a solution that will break almost every client. |
|
|
I think it's better to merge NAMESX stuff of 0002833 here. It seems mirc added certain support of NAMESX in version 6.17: When an IRC server sends NAMESX in it's 005 line, it send a PROTOCTL NAMESX. Basically exactly the idea we though of first, and it's backward compatible (non-NAMESX clients work fine) Now of course, we already know this thing is flawed-by-design[*] because when the PROTOCTL is sent and there's a set::auto-join.. then the client has joined already. So if you don't have any auto-join channels it would work 100% fine, if you do.. well then it will still work fine but will get a usual NAMES reply for that auto-join channel(s) instead of an extended one, so you keep the desynch problem for the auto-join channel(s). Now I also noticed XChat 2.0.0(pre..) added this PROTOCTL NAMESX thing 2-3 years ago, somehow this never got communicated to us (or me). I've only seen reactions like "just send the @+etc because <myfavoriteclient> can deal with it [eg: xchat], so all clients should!" ;p. I think I'll implement this NAMESX thing soon then (so will be in 3.2.5), it's really easy to code (that is not the problem). [*: unless client coders would send PROTOCTL NAMESX pre-reg even before they see the 005 and ignore any "PROTOCTL: unknown command" lines, that would solve everything, but.. I know it's not that elegant ;p] |
|
|
Maybe worth adding: this does not mean we give up negotiation protocols or anything, just adding this as one "standard" to enable things. |
|
|
Added in CVS [.469], Changelog entry follows: - Added NAMESX support, seeing both mIRC (5.17) and XChat support this. What this does is send all rights of all users on the channel in the NAMES reply (eg: @+Syzop if the user is +ov) instead of only the highest one (@Syzop in previous example). We only do so if the client explicitly requested this via a NAMESX in a PROTOCTL message (eg: 'PROTOCTL NAMESX'). Note that there is a glitch: since most clients only send the PROTOCTL NAMESX after they see NAMESX listed in the 005 announce message this has the effect that if there are set::auto-join channels present (where users are automatically joined to by the server) the extended NAMES reply will not be sent for those channels, because from the IRC server' point of view the join happened before the PROTOCTL and hence it does not know the client wanted NAMESX at that point (the result is not catastrophic: the old-style NAMES is sent for those channels). Anyway, for all non-autojoin channels this works great. So still worth adding IMO. Originally suggested in 0000606. Side note: this does not mean we dropped the idea of (also) having a challenge-response system for good ;). |
|
|
that's pretty nice that mirc and unreal now supports this :) but it should be mirc 6.17 and not 5.17 i just used cvs update and tried to compile again but there is no src/modules/m_names.c |
|
|
Both fixed now :P (hm downside of edit, I only saw it after I added it ;p) |
|
|
This does appear to work. Resolved or is there some other outstanding issue here? |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-07-18 15:22 | AngryWolf | Note Added: 0003278 | |
| 2003-08-10 17:01 | erlendse | Note Added: 0003444 | |
| 2003-08-10 17:45 | syzop | Note Added: 0003445 | |
| 2003-10-30 22:04 | Rocko | Note Added: 0003892 | |
| 2003-10-30 22:13 | syzop | Note Added: 0003893 | |
| 2003-10-30 22:20 |
|
Note Added: 0003894 | |
| 2003-10-30 22:28 | Rocko | Note Added: 0003895 | |
| 2003-10-30 22:34 | syzop | Note Added: 0003896 | |
| 2003-10-30 22:44 | syzop | Note Edited: 0003896 | |
| 2003-10-31 05:48 |
|
Note Added: 0003898 | |
| 2003-10-31 05:50 |
|
Note Added: 0003899 | |
| 2003-10-31 14:58 | syzop | Note Added: 0003901 | |
| 2003-10-31 15:16 | syzop | Note Added: 0003903 | |
| 2003-10-31 22:04 | fez | Note Added: 0003909 | |
| 2003-10-31 22:07 | fez | Note Edited: 0003909 | |
| 2003-11-01 00:42 | syzop | Note Added: 0003910 | |
| 2003-11-02 09:39 | mister | Note Added: 0003927 | |
| 2003-11-03 15:15 | mister | Note Added: 0003950 | |
| 2003-11-03 19:33 |
|
Note Added: 0003951 | |
| 2003-11-04 10:24 | mister | Note Added: 0003964 | |
| 2003-11-04 13:15 | mister | Note Edited: 0003964 | |
| 2003-12-31 00:01 |
|
Note Added: 0004476 | |
| 2004-11-10 11:43 | syzop | Relationship added | has duplicate 0002167 |
| 2004-11-10 19:38 |
|
Relationship added | has duplicate 0002170 |
| 2005-02-19 14:24 | syzop | Relationship added | has duplicate 0002346 |
| 2005-03-04 16:54 | Stealth | Note Added: 0009415 | |
| 2005-03-04 16:59 | syzop | Note Added: 0009416 | |
| 2005-03-04 17:00 | syzop | Note Edited: 0009416 | |
| 2005-03-04 17:08 | Stealth | Note Added: 0009417 | |
| 2005-03-04 17:47 | vonitsanet | Note Added: 0009418 | |
| 2005-03-06 10:17 | Trocotronic | Note Added: 0009447 | |
| 2005-03-06 11:42 |
|
Note Added: 0009453 | |
| 2005-03-06 13:16 | Trocotronic | Note Added: 0009457 | |
| 2005-03-06 13:33 |
|
Note Added: 0009460 | |
| 2006-02-24 07:10 | syzop | Note Added: 0011292 | |
| 2006-02-24 07:10 | syzop | Relationship added | related to 0002833 |
| 2006-02-24 07:16 | syzop | Note Added: 0011294 | |
| 2006-02-25 19:07 | syzop | Note Added: 0011299 | |
| 2006-02-26 01:36 | penna | Note Added: 0011300 | |
| 2006-02-26 01:46 | penna | Note Edited: 0011300 | |
| 2006-02-26 07:31 | syzop | Note Added: 0011302 | |
| 2006-06-05 08:53 | syzop | Relationship added | has duplicate 0002948 |
| 2007-04-15 21:15 | WolfSage | Note Added: 0013427 | |
| 2007-04-16 09:59 |
|
Status | acknowledged => resolved |
| 2007-04-16 09:59 |
|
Resolution | open => fixed |
| 2007-04-16 09:59 |
|
Assigned To | => stskeeps |
