[IRCServices Coding] More bugs and suggestions for Version 5.0
achurch at achurch.org
Fri Feb 15 23:56:52 PST 2002
1) Will consider.
2) It's been there for ages, where have you been?
3) Fixed (this is a bug in DROPNICK preventing dropping forbidden nicks and
has nothing to do with #).
4) I thought this was in the TODO list but it looks like not; added.
5) No; I don't see that this is something Services needs to do.
6) No; it ought to be common enough knowledge that channel names begin with #.
7) No; see above.
8) If the suspension doesn't expire then the channel won't either. I do
agree the text is a bit misleading.
9) No; unnecessary complexity.
10) No; unnecessary complexity (as mentioned in the previous mail).
achurch at achurch.org
>1) Suggestion: httpd module - nickname and channel lists - add an indicator
>for noexpire, forbidden, suspended etc to the lists in a similar way to the
>in IRC list command.
>2) Suggestion: /cs list and /ns list - add option to list suspended
>nicknames and channels to bring in line with the forbidden and noexpire
>options currently available.
>3) Bug: Services allows some commands to operate on #nickname. It is
>possible for example to forbid #nickname.
>/ns forbid #nickname
>-NickServ- Nick #nickname is now forbidden.
>/ns dropnick #nickname
>-NickServ- Internal error--unable to process request.
>/ns info will operate on an invlaid nick e.g.
>Nick #nick isn't registered.
>Where commands are used including a # character, or indeed any unsupported
>character, the response might be better as:
>-NickServ- Nick invalidnickname may not be registered or used.
>-NickServ- Nick invalidnickname contains invalid characters. then supply
>list of valid characters
>Services should explicitly not support # in all nickserv commands to avoid
>Finally, maybe services could also do a similar thing to the '#' channel on
>startup to clear out these nicks that are now stuck in my database :)
>4) Suggestion: /cs forbid and /ns forbid - introduce reason field for
>forbid in a similar manner to the suspend command.
>5) Suggestion: Services admin /cs drop and /ns dropnick - Add a reason
>field which is broadcast through globops and logged along with the drop
>command. Useful for working out later why a channel or nickname was
>6) Text bug: '/cs drop channel' produces:
>-ChanServ- Syntax: FORBID channel
>-ChanServ- Type /msg ChanServ HELP FORBID for more information.
>Suggest that it be changed to "FORBID #channel", and/or additional
>information explaining that a # prefix is required for channel names.
>7) Text bug related to 6 - /cs drop channel produces:
>-ChanServ- Channel channel isn't registered.
>which although correct, to be consistent with the requirement of the prefix
># ought to produce a failure message and the suggested additional
>information about the prefix listed in 6.
>8) Bug - either in text or operation - /cs help suspend produces the
>-ChanServ- Unlike a forbidden channel, a suspended one does not
>-ChanServ- lose its information and will expire!
>However, such channels do not seem to expire. As an example, a channel that
>was registered and suspended in November 2001 still remains suspended
>-ChanServ- Registered: Nov 22 10:11:24 2001 GMT
>-ChanServ- Last used: Nov 22 23:53:18 2001 GMT
>-ChanServ- Channel #modshack is suspended and may not be used or identified
>If the help text means that they would expire if unsuspended, then the text
>ought to be changed to reflect this. The problem appears to be in the
>version 4.5.x series as well as version 5 since the channels I have noticed
>it on were originally suspended under a version of 4.5.x and remained
>unexpired after migrating to 5.0.
>9) Suggested config option to limit guest nick length. The new guest nicks
>can end up using a full 9 digit precision depending on IRCd limits which on
>smaller networks makes them seem a little excessive. It would be nice if
>there was a configuration ption to limit this. Obviously such option would
>have to be accompanied by information on the minimum length requirement.
>10) Suggestion wrt IDENTIFY command: Although generally I have not found
>any reasons to consider or suggest aliases for existing services commands
>since they can generally be scripted client side and merely add confusion
>to the command list, I have found one "alias" that I do implement within
>our services which might prove useful to everyone. That is the addition of
>the command 'ID' to perform the job of 'IDENTIFY' with nickserv and
>The main benefit I have found is since this is a command which the majority
>of users will use every time they log on, is that people coming from other
>networks and services packages have the option of both so can quite easily
>use this primary services command in the form they already know to identify
>without having to rescript. It has helped groups of people move from other
>networks very easily and I find once their basics are shown to just work,
>they do not mind so much if commands for say access list management are
>different. The xOP module has also been very helpful for such groups.
>There is also an advantage of being simple to provide appropriate help text
>for since it will not affect current translations.
>The other maybe less obvious benefit is less typing for people like myself
>that avoid scripts and automatic identification. :)
>Well I think that's it ... for today at least :)
>To unsubscribe or change your subscription options, visit: