View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003528 | unreal | ircd | public | 2007-09-09 05:46 | 2007-11-20 20:53 |
| Reporter | Shining Phoenix | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.6 | ||||
| Summary | 0003528: Feature: Nickname holding | ||||
| Description | You know how /ns release is needed after services has taken your nick? That sucks. I have a solution. /svshold <nickname that can't be used by anyone> <except for this person> Scenario: Bob connects. Bob forgets to identify. Bob is now known as Guest1234 /svshold Bob Guest1234 #Now, only Guest1234 is allowed to do /nick Bob #The svshold will expire after a minute Guest1234 is now known as Bob. Bob identifies. As you see above, Bob didn't get an error when he tried /nick and didn't need to do /ns release. Two less annoying things to put up with. Once you have implemented this feature, services coders will have the option of using it. Of course services won't be recoded to always do /svshold, they'd just do something like release two versions, or add a new option to compiling, or add an option to the conf etc. This will make people's lives easier! | ||||
| 3rd party modules | |||||
|
|
but why should Guest1234 be allowed to change nick to Bob during that period? isn't the temp qline meant so nobody can't, ESPECIALLY him (failed to identify). the only reason I can think of is, after the nickchange and temp qline he has identified in some way that he really is Bob, so he should be able to use Bob again. Well, in that case, the temp qline can be removed at that time, and no need for coding an exception system. [if you even want to go further and like it, you could even svsnick him] |
|
|
Mm, this feature would be more useful for when a user does /ns recover or /ns ghost. |
|
|
If he is meant to be allowed to use it again immediately after a command, it should just not add the qline. If he isn't meant to be able to simply change back to the nick and resume using it, as in the case of not identifying, to stop them simply resuming using a nick they aren't identified for, then a qline makes sense. Services using a silly option from the above would be a flaw with them, wouldn't it? I can't see why a per-person exception would be needed, as in the second case it tends to be a matter of "no one, ESPECIALLY this person", as syzop said. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-09-09 05:46 | Shining Phoenix | New Issue | |
| 2007-09-10 04:49 | syzop | Note Added: 0014767 | |
| 2007-09-10 23:37 | Shining Phoenix | Note Added: 0014770 | |
| 2007-09-17 11:14 | Namegduf Live | Note Added: 0014778 | |
| 2007-11-20 20:53 | syzop | QA | => Not touched yet by developer |
| 2007-11-20 20:53 | syzop | U4: Need for upstream patch | => No need for upstream InspIRCd patch |
| 2007-11-20 20:53 | syzop | Status | new => closed |
| 2007-11-20 20:53 | syzop | Resolution | open => no change required |
