briancline/issuestest

Sandbox to test automated import of Google Code issues to GitHub issues.

issuestest's Issues

CS needs SHOW BAD command to list badchan masks

Originally filed by brian.cline on 2009-06-11T01:39:50

Problem arising from the current lack of this feature:
Admins have no way of seeing the badchan list!

Types/groups of users affected by the lack of this feature:
Admins

Full purpose and description of new feature:
Add a 'BAD' attribute to the SHOW command that will list all badchan masks.

CS user protection needs to be implemented

Originally filed by brian.cline on 2009-06-05T17:24:36

Problem arising from the current lack of this feature:
Channel users with higher levels than others may not be automatically protected by CS
against kicks, bans, and deops.

Types/groups of users affected by the lack of this feature:
Channel users.

Full purpose and description of new feature:
Three checks need to be performed at specific times:

• Deop: Check if deopped user has access, is protected, and level is greater than or equal
  to source's level.
• Ban: Check if ban matches any present users having an access level greater than or equal
  to source's level.
• Kick: Check if victim has access, is protected, and level is greater than or equal to
  source's level.

If any of the above are true, the action should be reversed and the offending user deopped.

Bot object doesn't provide behind-the-scenes outgoing mode processing

Originally filed by brian.cline on 2009-06-09T01:26:45

What steps will reproduce the problem?

1. Ask Bot::mode() for a change
2. Observe affected memory structures, noticing lack of change in modes that were just requested

What is the expected output? What do you see instead?
The Bot object, when asked to perform a raw mode change, should still process the mode change
the same way it would if we received it from the uplink. Instead, it simply passes it along and does
not process it in any way.

The Bot::mode() method should parse the mode string, remove any redundancies, perform the
necessary actions in memory, split the change into multiple actions if we request more than six
mode changes, and send along the changes to our uplink.

CS not populating register_date field

Originally filed by brian.cline on 2009-05-26T17:26:20

What steps will reproduce the problem?

1. Register a channel with CS.
2. Examine new channel record in channels table

What is the expected output? What do you see instead?
Should see the same date as the 'create_date' field. Instead, I see a null datetime, or '0000-00-00
00:00:00'.

While create_date and register_date should, ideally, provide the same exact date, create_date is
more of a database model metadata field. That is, it is not used in the application itself but more on
the backend side to show when the record itself originated. In the future there may be a supported
script that can migrate data between versions or move it to a different server; in such a case, it is
quite possible that create_date would differ unless a straight export and import were performed.

CS not populating register_date field

Originally filed by brian.cline on 2009-05-26T17:26:20

What steps will reproduce the problem?

1. Register a channel with CS.
2. Examine new channel record in channels table

What is the expected output? What do you see instead?
Should see the same date as the 'create_date' field. Instead, I see a null datetime, or '0000-00-00
00:00:00'.

While create_date and register_date should, ideally, provide the same exact date, create_date is
more of a database model metadata field. That is, it is not used in the application itself but more on
the backend side to show when the record itself originated. In the future there may be a supported
script that can migrate data between versions or move it to a different server; in such a case, it is
quite possible that create_date would differ unless a straight export and import were performed.

OS glines clones with private IPs

Originally filed by brian.cline on 2009-05-26T21:58:25

What steps will reproduce the problem?

1. Load clones from the same private-range IP with clone glining turned on.

What is the expected output? What do you see instead?
OS glines private-range IPs that exceed the max clone count. OS should only
gline clones if they originate from a public IP address, not a private one.
Services tend to have private addresses and it is useless and wasteful to
have it issuing private-class glines.

CS not populating register_date field

Originally filed by brian.cline on 2009-05-26T17:26:20

What steps will reproduce the problem?

1. Register a channel with CS.
2. Examine new channel record in channels table

What is the expected output? What do you see instead?
Should see the same date as the 'create_date' field. Instead, I see a null datetime, or '0000-00-00
00:00:00'.

While create_date and register_date should, ideally, provide the same exact date, create_date is
more of a database model metadata field. That is, it is not used in the application itself but more on
the backend side to show when the record itself originated. In the future there may be a supported
script that can migrate data between versions or move it to a different server; in such a case, it is
quite possible that create_date would differ unless a straight export and import were performed.

CS not populating register_date field

Originally filed by brian.cline on 2009-05-26T17:26:20

What steps will reproduce the problem?

1. Register a channel with CS.
2. Examine new channel record in channels table

What is the expected output? What do you see instead?
Should see the same date as the 'create_date' field. Instead, I see a null datetime, or '0000-00-00
00:00:00'.

While create_date and register_date should, ideally, provide the same exact date, create_date is
more of a database model metadata field. That is, it is not used in the application itself but more on
the backend side to show when the record itself originated. In the future there may be a supported
script that can migrate data between versions or move it to a different server; in such a case, it is
quite possible that create_date would differ unless a straight export and import were performed.

CS not populating register_date field

Originally filed by brian.cline on 2009-05-26T17:26:20

What steps will reproduce the problem?

1. Register a channel with CS.
2. Examine new channel record in channels table

What is the expected output? What do you see instead?
Should see the same date as the 'create_date' field. Instead, I see a null datetime, or '0000-00-00
00:00:00'.

While create_date and register_date should, ideally, provide the same exact date, create_date is
more of a database model metadata field. That is, it is not used in the application itself but more on
the backend side to show when the record itself originated. In the future there may be a supported
script that can migrate data between versions or move it to a different server; in such a case, it is
quite possible that create_date would differ unless a straight export and import were performed.

CS not populating register_date field

Originally filed by brian.cline on 2009-05-26T17:26:20

What steps will reproduce the problem?

1. Register a channel with CS.
2. Examine new channel record in channels table

What is the expected output? What do you see instead?
Should see the same date as the 'create_date' field. Instead, I see a null datetime, or '0000-00-00
00:00:00'.

While create_date and register_date should, ideally, provide the same exact date, create_date is
more of a database model metadata field. That is, it is not used in the application itself but more on
the backend side to show when the record itself originated. In the future there may be a supported
script that can migrate data between versions or move it to a different server; in such a case, it is
quite possible that create_date would differ unless a straight export and import were performed.

CS not populating register_date field

Originally filed by brian.cline on 2009-05-26T17:26:20

What steps will reproduce the problem?

1. Register a channel with CS.
2. Examine new channel record in channels table

What is the expected output? What do you see instead?
Should see the same date as the 'create_date' field. Instead, I see a null datetime, or '0000-00-00
00:00:00'.

While create_date and register_date should, ideally, provide the same exact date, create_date is
more of a database model metadata field. That is, it is not used in the application itself but more on
the backend side to show when the record itself originated. In the future there may be a supported
script that can migrate data between versions or move it to a different server; in such a case, it is
quite possible that create_date would differ unless a straight export and import were performed.

NS needs command logging

Originally filed by brian.cline on 2009-06-05T16:50:42

Problem arising from the current lack of this feature:
No way for NS admins to monitor commands sent to the bot.

Types/groups of users affected by the lack of this feature:
NS administrators.

Full purpose and description of new feature:
Implement command logging to the log channel specified in the INI file.

Please provide any additional information below.
Implementation should be as clean as possible so as not to require individual
calls from handler files. May need to slightly rework PRIVMSG handler.

CS needs command reporting

Originally filed by brian.cline on 2009-06-05T16:50:05

Problem arising from the current lack of this feature:
No way for CS admins to monitor commands sent to the bot.

Types/groups of users affected by the lack of this feature:
CS administrators.

Full purpose and description of new feature:
Implement command logging to the log channel specified in the INI file.

Please provide any additional information below.
Implementation should be as clean as possible so as not to require individual
calls from handler files. May need to slightly rework PRIVMSG handler.