[IRCServices Coding] More bugs and suggestions for Version 5.0

[Mark Hetherington]

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.