This is a great program and shows great potential. But it's not yet ready for prime-time.
Here are just a few of the bugs I have found (other than the sound not working and the canned messages not working which I have already fixed).
1) Bug: If an operator has loaded a picture and then wishes to turn that off, they get a SQL error. (this should be a very simple fix, as it appears to be a simple typo).
What is the exact error? I dont get this error in my installation copy, unable to duplicate. It will be helpfful to have exact step by step to duplicate the issue.
Well, now I can't duplicate the error. I just tried it several times and it now seems to be working fine. When I first reported this, it happened everytime without fail. There are still some issues that I'm not sure about however. When you change the status of Display Picture from Yes to No, does it delete the picture? If not, then it should remain visible with an active/inactive status on it. I changed it to No, saved it, and then back to Yes, and saved again. No picture shows up, meaning I have to re-upload the picture each time. Not a big deal, but something that may need to be addressed.
2) Bug: If only one operator is chatting and someone else requests a chat, that same operator is asked to accept or decline. If they press accept while they are already chatting, it will end the current chat and take the next one. Here's a feature request: Have the ability to limit the number of chats each operator is allowed to take, and open additional pop-up chat windows if the operator decides to chat with a second or even third person (if allowed). This way one operator can handle 2 or 3 chats at the same time, which is very useful. Right now, one operator, one chat...
Havent seen this happen either, but havent had the situation occur often enough. Going to test this out and see what's up with it.
This still happens... I was the only operator logged in and chatting with another person in the office. I then received another chat request from someone else in the office. Shouldn't be happening if I'm already chatting (unless of course there is a setting to limit the number of chats per operator to 3 or something like that). In any event, if I then accepted the 2nd chat, the first one disappeared. The first person I was chatting with didn't notice anything, and kept on typing, but I was not seeing his responses any longer. I was chatting with the 2nd person only, and there didn't appear to be any way to go back to the first chat session. This is a huge bug... Either it should not allow an operator already in chat to accept another chat (bad idea, especially if you want to have each operator handle 2 or 3 chats simultaneously), or the operator should be able to accept the chat, but be able to switch back and forth between the chats...
3) Bug? (or ignorance issue): I've not been able to figure out the cobrowse and coforms. I selected it when I generated my icons, but don't know how or where to initiate that so I can view the page just as the visitor is seeing it. Perhaps I'm misunderstanding the term "co browse"
have never used this or tested it- mainly because in my install, the http_referer information is sufficient to know what the client is seeing, so, leaving this one to someone else to verify
Well, I think the problem is that I didn't understand (or perhaps still don't), what co-browse meant. I assumed it was the ability to view what the user is doing in real-time (or what page he/she is on and what they are currently doing/typing). But I read somewhere else, that it just allows me to initiate a chat with a visitor who has not requested a chat yet... This needs to be clarified, if that is the case.
4) Feature Request: Need more visitor statistics. Need to be able to view what pages each visitor hit and how long and the page (referrer) they came from (or page they were at last if on same site).
Doesnt monitoring already do this? It's a configuration setting in config file- to turn on or off these stats. We currently use this. However- I do plan on adding additional fields to it, but it's scheduled for HCL 3 - developing a plugin where admin can select specific fields from a visitor browser data or session that should also display in the monitor, and/or any sql queries or data to be pulled from another database... (I.E. Logged in clients in a control panel system, dont always give the info techs need, easier to have it displayed, such as username, client ID, email address, etc, etc)
Yes, I found this after submitting
5) Feature request: need time based and event based chat initiation. If a visitor has been on a certain page for a number of seconds or minutes, have it automatically initiate a chat request. Also, if a visitor is having a problem with a certain event on the page (such as logging in with a username/password) and has tried 3 times without success, have it initiate a chat request... These 2 are very important features.
Agree- this should be a switchable option- initiate chat if visitor has been on page xx seconds.
The second item- that really wouldnt be feasible, without a very specific, focused module (you'll need to hire someone to code it to your specific login system) because Login systems have a wide, *wide* variety of differences, parameters, etc.. it'd be impossible to account for every variation..
Yeah, I understand. and thought about this after I submitted it
6) Feature request: On the Administration page, there should be some stats as to how many visitors are current on any given page/site, how many operators are logged in and how many are chatting (and how many chats), and how many visitors are waiting for an operator... Administrators should be able to view this information at all times.
Great suggestion- It is something I'd had in the back of my mind, but not really a well formed idea.. this clarifies it quite a bit.
7) Feature request: Along with 6 above, if the waiting visitors hits a certain number (say 5), have an alarm sound on the admin panel or send an email (to an alias) telling them that more operators need to log on.
OK this one is a little tricky- visitors will have to repeatedly request chat..
I have a few things about the methods with this current system as it is that need to be worked out, so this might be worthwhile looking into.. More like it would just keep a statistic for how many chat requests were missed.. how many people are left hanging at the end when request times out if a ops are polled but never accept request.. for example.
Nope, I don't see that they need to request chat repeatedly... If they request a chat, and no operator answered it, they are given the option to leave a message. This is fine, now simply increment a counter that shows the administrator that this person has requested a chat and it went unanswered. The administrator then can either log in and initiate a chat with that same visitor (if they are still on the site) or ask another operator to log in and either initiate the chat with that person or wait to see if the visitor requests chat again, thereby making sure that someone is answering chats. If the visitor leaves site before an operator can chat with them, the counter simply goes to 0.
8 ) Bug: The update icon on the admin page says a new version (2.1.5) is available... But that's the version I'm already running. So something isn't updating the version check in upgrade.php.
Probably is a minor bug/flaw- might also possibly be related to session or cached page data....
it doesnt occur in the version I'm running....
Ok, I'll check this again.
Ok, that was more than a couple of feature requests
Overall, a pretty good list.. a few good ideas there.. hopefully you can provide more info on the bugs you see, and how to duplicate them..