The Config class and the configuration setup in general is not sustainable or scaleable. A better solution needs to be implemented.

Story

As a project developer
I want organized lists of messages
So that I can more easily determine which messages are used for which cases.

Requirements

• Messages class is split into multiple, logically-organized classes.
• All existing uses of messages are uplifted to use the new classes.

Design

Messages will be split based on use. I.E: Error messages, logging messages, messages sent to users.

Technical Design

We'll need a new folder under util for the messages. We will continue to use public final static String for each new class.

Need to write JavaDocs for SCM class.

https://github.com/somefriggnidiot/conbot/blob/master/src/main/server/ServerConnectionManager.java

Issue

Idlechecker can be started while already running, creating multiple simultaneous checkers.

Speculative Fix

A class-level boolean for the IdleChecker function class to be used as a isRunning indicator. start and stop should check to see if the IdleChecker is running, and disable it if so.

Story

As a bot manager
I want to control whether logs are sent to the console
So that I can control the flow of information

Requirements

Config fields are added to indicate whether or not we should log messages to the console.
Messages are sent to the console only when we opt for it in the config.
Manual testing has been done to ensure changes work and do not affect other changes.
Unit testing is added as necessary.

Technical Design

A new configuration field should be added per component. (JoinHandler, LeaveHandler, MessageHandler, basic logging, etc.)
All logging messages should belong to a component.

Story

As a project owner
I want unit tests for existing and future functionality
So that I can better ensure the quality of code changes.

Requirements

Unit tests are created for all existing classes that contain logic.
All existing issues requirements are updated to include adding/updating unit tests as necessary.

Formatting for "Connection" messages in the console log are not being formatted correctly.

Current Example:

2017-12-17 21:13:09[CONNECTION] somefriggnidiot (uid) connected to "Default Channel"

Ideal Example:

[2017-12-17 21:13:09] [CONNECTION] somefriggnidiot (uid) connected to "Default Channel"

Because of the nature of this issue, it is likely that ClientJoinHandler is not utilizing MessageHandler.

Story

As a bot developer
I want to abstract common, repeated code sequences into functions
So that I can create cleaner, less error-prone commands.

Requirements

• Common code sequences in commands are refactored out into Commands.java
• Tests added/updated as necessary.

Technical Design

• Move accessManager checks out and into a function.
• Look into injecting instance and/or API into commands

Story

As a developer
I want to cache commonly used information about clients
So that I can better streamline the use of that information.

Requirements

New object created to store info about connected clients.
All references to online or connected client information are uplifted to use the new object.
Manual testing has been done to ensure changes work and do not affect other changes.
Unit testing is added as necessary.

Technical Design

A "Client" (name TBD) object is created that stores ClientInfo and current channel of that client.
connectedUserList in SCM is uplifted to using new "Client" object.

Create a functionality for the bot to accept and handle chat commands.

Story

As a server administrator
I want to limit access to commands on a per-user basis
So that I can better restrict the usage of admin actions.

Requirements

Configuration updated to store access lists.
Unit test updated and/or created as necessary.
README updated.

Design

Permissions should be checked between receiving the command and handling it.
User-level access should override group-level access.

Technical Design

There will be a new config files, storing UIDs of users. Config will act as a whitelist, storing the values as lists. Each list will correspond to a different access level. The access levels will be broken down as follows, from most to least power:

• Owner: Full access.
• Super Administrator: Full access, but cannot modify owner.
• Administrator: Full access, but cannot modify configuration or roles.
• Moderator: Limited access to disciplinary actions.
• Sponsor: Access to commands affecting their own cosmetics.
• Normal: Default role. Can access basic chat commands that are largely unimportant and offer little functional value.
• Blacklisted: No access to any commands.

See #23 for similar story for groups.
"Normal" will not be in any list; any user without a role is assumed to be a normal user.

ServerConfigBuilder.java is missing JavaDocs.

When is this happening?

When sending a message over 1024 characters long to aserver/channel/user.

How does it function now?

The message cuts off.

How should it be functioning?

The message should be send in multiple pieces.

How will we know when this is fixed?

• Messages longer than the largest teamspeak message limit will be split into multiple messages when sent through the API.
• Tests are updated/added as necessary.
• Manual testing has been completed.

Story

As a server administrator
I want a log of when and where to clients move within the server
So that I can better understand the happenings of the server.

Requirements

A message is displayed in the console when clients change channels or are moved within the server.
The message displayed is dependent on the circumstances of their moving.
Manual testing has been done to ensure changes work and do not affect other changes.
Unit testing is added as necessary.

Technical Design

Listener and Handler will need to be created for ClientMovedEvent.
Handler should include cases for whether there was an invoker or not.

Story

As a client administrator
I want a chat command that lists connected user information
So that I can determine the target of future commands.

Requirements

Command added to list UID, ClientID, and username of target(s).
Manual testing has been done to ensure command works both on front end and back end.
README updated with information about command usage.

Design

Command should be able to be triggered from the client and the back-end.
Command should receive the following params: target (optional)
'Target' param should accept the following options:

• No value, where it returns information about all users.
• "@me", where it returns information about invoker.
• Any other string, which returns information about any user whose name matches the query.
  Response should be formatted and easy to read, containing (at minimum) the user's nickname, client ID, and unique ID. For example:
  User: somefriggnidiot | Client ID: 1 | UID: wuNgAy99zFpiNSmnS6i/lKHekLs=

Technical Design

UserInfoCommand.java created.
Command support added to handler in Commands.java

Story

As a server administrator
I want to manage access lists from the TeamSpeak client
So that I can better restrict the usage of admin actions.

Requirements

Chat command created to add or remove users to and from access roles.
Unit test updated and/or created as necessary.
README updated.

Design

Command should only be accessible by Owner and Super Admins.
Command should take three arguments: action (add/remove), target, access group.
Command should work on users as well as groups.

Technical Design

MORE DESIGN IS REQUIRED BEFORE THIS TASK CAN BE WORKED ON

Story

As a bot owner
I want to know why my bot fails to connect to my server
So that so that I can better troubleshoot the issue.

Requirements

• Stack traces are no longer shown on connection errors.
• Connection error messages pinpoint the cause of the error.
• Tests updated as applicable.

Design

Error messages should be used to concisely describe the source of the issue.
"Could not resolve host.", "You are banned from this server.", etc.

Technical Design

Tries and catches.

There appear to be missing messages from disconnections.
From general live testing, this appears to be mostly when clients lose connection.

Story

As a server administrator
I want a log of when and why clients leave
So that I can better understand the circumstances of their leaving.

Requirements

A message is displayed in the console when clients disconnect from the server, as well as whether or not the disconnect was forced for voluntary.
Manual testing has been done to ensure changes work and do not affect other changes.

Technical Design

Listener and Handler will need to be created for ClientLeaveEvent.
Handler should include cases for whether there was an invoker or not.

Configure build on Travis and ensure all is working.
https://docs.travis-ci.com/user/languages/java/

Story

As a bot owners
I want to save log messages to a file
So that I can review server activity at a later date.

Requirements

• Support is added for all existing logging messages to be able to be logged to a file.
• Message handler is updated to allow file logging.
• Config is updated to control granularity of file logging.
• Tests added/updated as applicable.
• Readme updated with example configuration and usage.

Design

A new logging file should be created for each day the bot is running (starting at system/environment 00:00), with each message on its own line.
Messages should use the same format and timestamp granularity as those logged to the console.

Technical Design

logToFile() method should be added to MessageHandler; should take care of actual logging of message.

Story

As a client administrator
I want a chat command that allows me to remove users from the server
So that I can better moderate my server.

Requirements

Command added to kick a player from the server.
Manual testing has been done to ensure command works both on front end and back end.
README updated with information about command usage.

Design

Command should be able to be triggered from the client and the back-end.
Command should receive the following params: target (required), reason (required)
'Target' param should accept the numeric clientId of the target.
'Reason' should contain any string following the clientId.

Technical Design

KickUserCommand.java created.
Command support added to handler in Commands.java

Story

As a bot owner/administrator
I want family friendly humor added to the bot
So that I can better entertain my server users.

Requirements

• Add "DadMode" command to bot that accepts "enable" and "disable" as arguments, as well as applicable aliases.
• Unit tests added/updated as necessary.
• Documentation updated to reflect new commands/functionalities.

Design

Command should enable or disable the dad mode functionality.
When dad mode is enabled, bot respond to any message that starts with "I'm X", "I am X", "Im X" with "Hi, X. I'm Dad!"

Technical Design

Will need to add command to manage module.
Will need to add check in TextMessageEventHandler to see if message applies to dad mode.

Story

As a developer
I want a flexible message handler
So that I can more easily send a message to multiple sources.

Requirements

MessageHandler constructor accepts attributes common to all message types.
MessageHandler methods are chain-able to provide multiple messaging methods in one line.

Technical Design

Common Attributes: Message
Specific Attributes:

• Console & File Logging: Prefix, LoggingLevel, Timestamp
• Server Messaging: API, message type, target

Story

As a developer
I want a list of logging message prefixes
So that I can increase consistency in program output..

Requirements

• Console message prefixes are listed in an enum.
• All existing uses of console message prefixes are uplifted to use the enum.
• Manual testing is done to ensure nothing was broken by the change.

SCM should check to ensure config params are present before continuing.
SCM should allow storage of instance name.

This issue requires more information before work begins.

Story

As a server administrator
I want to limit access to commands to specific groups
So that I can better restrict the usage of admin actions.

Requirements

Configuration updated to store access lists.
Unit test updated and/or created as necessary.
README updated.

Design

Permissions should be checked between receiving the command and handling it.
Commands should be categorized based on required access levels.

Technical Design

There will be a new config files, storing IDs of server groups. Config will act as a whitelist, storing the values as lists. Each list will correspond to a different access level. The access levels will be broken down as follows, from most to least power:

• Owner: Full access.
• Super Administrator: Full access, but cannot modify owner.
• Administrator: Full access, but cannot modify configuration or roles.
• Moderator: Limited access to disciplinary actions.
• Sponsor: Access to commands affecting their own cosmetics.
• Normal: Default role. Can access basic chat commands that are largely unimportant and offer little functional value.
• Blacklisted: No access to any commands.

"Normal" will not be in any list; any user without a role is assumed to be a normal user.

Story

As a client administrator
I want idle users to be automatically moved after some time
So that I can better judge the server's activity.

Requirements

Configurable idle-checker/mover is created.
Manual testing has been done to ensure command works both on front end and back end.
README updated with information about functionality usage.

Design

Functionality should include commands to change configuration.
Commands required:

• on/off control
• change threshold
• change action (kick/move)
• destination channel (if move)
• ignore list management (channels and groups not checked for idle)

Technical Details

A config file will need to be created for storage of the different options available.
All commands should operate as functions of a parent command. (I.E. !idlecheck on, !idlecheck set-time 30 minutes, !idlecheck add-ignore group, !idlecheck set-action kick)

Tech Design

Create command and config file, as well as a class that contains the logic for checking/moving idle users.
Logic class will run on a timer to continuously check for idle users when enabled.

Issue

In some rare cases, the bot will continuously move a user to AFK while idlechecker is active, even if the user is not above the activation threshold.

Speculative Cause

It's possible that this is happening due to an error in the bot's running environment or from a connection issue. There was no console output during this occurring.

Story

As a bot administrator
I want to know if IdleChecker is running and what its MO is
So that I can better understand what features are active.

Requirements

• Command exists to display information about the current status of IdleChecker functionality.
• Tests updated as necessary.
• Readme updated with command usage.

Design

Command should be !idlechecker status or default response for !idlechecker without params.
Response should include whether or not IdleChecker is running, as well as the idle time threshold.

Technical Design

No new command class is necessary; this logic can go into IdleCheckerCommand#handle(String).

Story

As a bot developer
I want to be able to easily return messages received from TextMessageEvents to their received target
So that I can more efficiently control the flow of messages and lessen the occurrence of errors.

Requirements

• MessageHandler gets new "ReturnToMedium" or similarly named method that sends the message to the medium it was sent to.
• Unit tests added/updated as necessary.

Technical Design

Method should go into MessageHandler.java as another possible command to be tacked onto a MessageHandler object.
Method should receive a TextMessageEvent, check the target of that event, then return it to that target. If the target was CLIENT, the message should be sent to the invoker.

Create console command that allows connection to instance (by matching config instance name) and disconnection. Allow disconnection from console and client.

THIS REQUIRES MORE INFORMATION AND DESIGN BEFORE WORK IS READY

Story

As a bot admin on a server
I want to be able to call the bot to my channel
So that I can use channel chat for commands and be less disruptive to the server.

Requirements

• "!comehere" command added.
• Tests added/updated as necessary.
• Documentation updated to reflect new command.

Design

Command should not take any parameters. When triggered, the bot should move to the channel of the invoker and announce itself in channel chat.

Technical Design

Commands.java will need to include new case for this command.
New command class will need to be created for handling this command.

Story

As a bot administrator
I want to easily access IdleChecker functionalities without having to remember exact command names
So that less time is spent retyping closely related commands.

Requirements

• IdleChecker commands and arguments accept logical aliases.
• Tests updated as necessary.
• Readme updated with command usage.

Design

Base command (idlechecker) should accept the following aliases: idlecheck, idle
Argument enable should accept: on
Argument disable should accept: off

Technical Design

No new command class is necessary; this logic can go into IdleCheckerCommand and Commands.