View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002990 | unreal | ircd | public | 2006-07-05 12:31 | 2012-12-26 19:33 |
| Reporter | tabrisnet | Assigned To | |||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux/x86 | OS | Debian Linux | OS Version | testing |
| Product Version | 3.2.5 | ||||
| Target Version | 3.3-alpha0 | Fixed in Version | 3.4-alpha1 | ||
| Summary | 0002990: Q:Line Holds and "Erroneous Nickname" | ||||
| Description | Seems that users are getting confused by the "Erroneous Nickname" message (and it's not just the part from the qline reason... I played with that already). The short and long is that I think that we should look into something like "Enforced nickname" or "Services Enforced Nickname" for qline H (tho not normal qline). | ||||
| Additional Information | I agree that not many services packages use qline holds yet (tho I understand that Anope 1.7.x can use them, but I don't think they're on by default yet). I started using them to eliminate the races btwn svsnick, nickchange, signon-enforcer. With qlines that's never an issue. Unfortunately, we now live in the MSN & AIM generation, where users are not familiar with IRC or what certain things mean, and often are 'limited literate'. They're not illiterate, but they have very limited understanding, even those who would be considered native speakers. I hate it, but must live with it. I am not seeking that the 432 message be changed per se, but that we might use a custom 432 here... I'd even consider using 433, although that has its own problems (NickServ stole my nick! Check bash.org for examples). I want a singular clear message that they'll understand. Plus "Erroneous Nickname" usually means an illegal or inappropriate nickname, not a nick that is being enforced. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
I disagree. If a user doesn't know what a word means, they should look it up or ask someone. This IS the Internet. Information is readily available, and easy to access. |
|
|
But wtf does "Erroneous" have to do with it being services enforced? |
|
|
Isn't Erroneous in RFC1459? I mean, it would cause clients to not touch a nick and realize they can't switch to it, so it serves it's purpose? Does the message -actually- matter for clients? Anyone want to test? |
|
|
A client itself probably won't check the message. I think the point being made is the *humans* behind the client don't get it. And "Erroneous nickname" is pretty vague. Nearly every other case where we deny something, we tell the user who tried it why (gline: * Closing Link blah (User has been banned from <network> (<blarp>), for example). Perhaps our 432 should start including the qline message? (edit: er, actually, don't we do that already?) (edit2: yes we do: /* 432 ERR_ERRONEUSNICKNAME */ ":%s 432 %s %s :Erroneous Nickname: %s" - so is this really an issue?) |
|
|
The problem is that the users just see "Erroneous nickname" and think that their nick is not allowed, rather than merely services-enforced. As I said, I tried editing the qline reason to something that tells a lot more, but users were still confused. |
|
|
* WolfSage :Erroneous Nickname: Being held for registered user If a user is too lazy to read that whole sentence, that's their problem. |
|
|
Well, back when I had a large population of kids (14 and under) I had a lot of that problem. The channel moved a while ago so it's less of a problem now, but the fact is that assuming or requiring intelligence shifts the burden not onto the stupid user but onto the support staff. Your attitude on this is making me think I should have just patched the code myself. |
|
|
Before we start misunderstanding eachother here.. Would it at all be a problem if we simply made the 432 ":%s 432 %s %s :%s" where the actual reason is the reason that is set in Q:line etc etc? I mean, can anyone come with a widely used script/client that REQUIRES the Erroneous nickname being in it? I'm not against removing the Erroneous part, atleast. |
|
|
I'm reasonably confident that irssi doesn't care, as it just pays attn to the numeric, and then prints the payload. I poked around the code, and numeric 432 calls event_received which calls print_event_received which doesn't do any filtering on the content itself. |
|
|
Confirmation being that for we switch to the prefix not being Erroneous nickname: but just the actual error itself. I admit this breaks RFC1459 but it really seems a lot better this way. 432 ERR_ERRONEUSNICKNAME "<nick> :Erroneus nickname" - Returned after receiving a NICK message which contains characters which do not fall in the defined set. See section x.x.x for details on valid nicknames. |
|
|
Implemented in .2371 |
|
|
http://hg.unrealircd.org/hg/unreal/rev/18324232791c |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-07-05 12:31 | tabrisnet | New Issue | |
| 2007-04-15 20:40 | WolfSage | Note Added: 0013424 | |
| 2007-04-15 21:01 | tabrisnet | Note Added: 0013426 | |
| 2007-04-18 05:05 |
|
Note Added: 0013502 | |
| 2007-04-18 05:05 |
|
Status | new => acknowledged |
| 2007-04-19 19:22 | aquanight | Note Added: 0013610 | |
| 2007-04-19 19:22 | aquanight | Note Edited: 0013610 | |
| 2007-04-19 19:23 | aquanight | Note Edited: 0013610 | |
| 2007-04-19 19:25 | tabrisnet | Note Added: 0013611 | |
| 2007-04-19 20:30 | WolfSage | Note Added: 0013612 | |
| 2007-04-19 21:05 | tabrisnet | Note Added: 0013613 | |
| 2007-04-20 10:10 |
|
Note Added: 0013616 | |
| 2007-04-20 10:32 | tabrisnet | Note Added: 0013618 | |
| 2007-04-21 03:13 |
|
Note Added: 0013623 | |
| 2007-04-21 03:13 |
|
Status | acknowledged => confirmed |
| 2007-04-24 05:25 |
|
Status | confirmed => resolved |
| 2007-04-24 05:25 |
|
Fixed in Version | => 3.3-alpha0 |
| 2007-04-24 05:25 |
|
Resolution | open => fixed |
| 2007-04-24 05:25 |
|
Assigned To | => stskeeps |
| 2007-04-24 05:25 |
|
Note Added: 0013653 | |
| 2011-07-19 14:09 | syzop | Assigned To | stskeeps => |
| 2011-07-19 14:09 | syzop | Status | resolved => needs re porting |
| 2011-07-19 17:11 | syzop | Target Version | => 3.3-alpha0 |
| 2012-12-26 19:33 |
|
Note Added: 0017280 | |
| 2012-12-26 19:33 |
|
Status | needs re porting => resolved |
| 2012-12-26 19:33 |
|
Fixed in Version | 3.3-alpha0 => 3.4-alpha1 |
| 2012-12-26 19:33 |
|
Assigned To | => nenolod |
