458793 - Room monitors should be able to open/close the workgroup

Status: RESOLVED FIXED

(support.mozilla.org Graveyard :: Chat, enhancement)

Description

[Matthew Middleton (:zzxc)]

There should be a feature allowing agents with room monitor to open/close the workgroup.  This will be implemented with a command that room monitors can issue to the workgroup itself.

Comment 1

[Matthew Middleton (:zzxc)]

Attachment: Implements a command-based interface to control the workgroup

This adds an interface to control the workgroup via XMPP.  Room monitors can open/close the workgroup, and everyone can set their personal chat limit.  It adds four commands to the existing ChatBot interface accessible by private messaging the workgroup.

*admin open: Opens the workgroup (room monitors only)
*admin close: Closes the workgroup (room monitors only)
*admin status: Prints the current status of the workgroup
*admin limit <number>: Sets the agent's personal MaxChats to number

Comment 2

[[:Cww]]

A few comments: "Ready to open" isn't clear.  Use "Live Chat will open as soon as a helper sets available" or something more descriptive.

There should be some checking of the integer used in limit commands.  We probably don't want it to go higher than a global max chats and it should be at least 1.

Comment 3

[Matthew Middleton (:zzxc)]

Attachment: Improve limit functionality and update wording

(In reply to comment #2)
> A few comments: "Ready to open" isn't clear.  Use "Live Chat will open as soon
> as a helper sets available" or something more descriptive.
> 
> There should be some checking of the integer used in limit commands.  We
> probably don't want it to go higher than a global max chats and it should be at
> least 1.

I changed the limit command to be more useful.  It now allows room monitors to set other agents' limits, and everyone except room monitors is subject to a maximum limit.  This "maxMaxChats" setting is currently hardcoded to 5 - it should be added to the database schema as a configurable option if this feature is accepted upstream.  Additionally, a chat limit of 0 (only configurable by room monitors) forces the agent to be Away until the agent logs in again.  This prevents the agent from receiving more chat offers or keeping the queue open, useful if an agent forgets to manually set Away.

This also changes the "ready" wording to "will be open when when an agent becomes available".

Comment 4

[Austin King [:ozten]]

Comment on attachment 352883 [details] [diff] [review]
Improve limit functionality and update wording

I am not familiar with the project and don't have a local installation to patch and run the code.

In general this looks good. Some minor feedback:

make mutually exclusive blocks part of the same if/else structure: it seems arguments[1] can be open/close/status/limit.

Consider pulling out user id into a temporary variable early on in handleAdminCommand to avoid repetitive and wordy 
session.getUserJID().toBareJID()

If logging is used on the project, consider logging where you catch general Exception and send back syntax help.

handleAdminCommand is a bit long.

I found
if ((max < 0) || ((max < 1) && (!workgroup.isRoomMonitor(session.getUserJID().toBareJID())))) {
a little confusing on quick read. Maybe 
if ((max < 0) || ((max = 0) && (!workgroup.isRoomMonitor(session.getUserJID().toBareJID())))) {

Again all minor nitpicks. Great work. I don't see any real issues, am marking +.

Comment 5

[Matthew Middleton (:zzxc)]

Attachment: Address review comments (checked in)

Thanks for the review.  I addressed your comments and checked this in.  (r20864)