[IRCServices Coding] More bugs and suggestions for Version 5.0

[Andrew Church]

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).

  --Andrew Church
    achurch at achurch.org
    http://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.
>or 
>-NickServ- Nick invalidnickname contains invalid characters. then supply 
>list of valid characters
>Services should explicitly not support # in all nickserv commands to avoid 
>confusion. 
>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 
>dropped. 
>
>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 
>following information:
>-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 
>today. 
>-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 
>for.
>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 
>chanserv. 
>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 :)
>
>-- 
>Mark.
>
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding