QueueMetrics 1.4.1 out today

[QueueMetrics]

The latest version of QueueMetrics is out today.
This is mainly a bug-fix releae over 1.4.0, with a lot of stuff fixed and improved - the most important new addition is that QueueMetrics now supports dynamic logins per queue if you run under Asterisk 1.4.

1.4.1 - 2007-09-05
====================
- Support for dynamic queue logon through AddMember and RemoveMember verbs (EXPERIMENTAL) (#134, #137)
- Pause codes are now shown on the Realtime page (#154)
- Raw agent sessions: it is now possible through a configuration switch to see ALL agent sessions and not only those where they've taken at least one call. (#171)
- It is now possible to make the agent code on the agent's page unchangeable. (#174)
- It is now possible to hide the export buttons on the Realtime page (#51)
- The licence page now shows Java time and MySql time, to make it easy to spot timing problems. (#178)
- Agents without a password can now be imported directly from agents.conf, their password in QM being the same as their agent code (e.g. 'Agent/101' will have passord '101') (#172)
- The default configuration file that ships with QM is compatible with TrixBox, as it's teh most common environment. (#173)
- The time zone offset value was not working correctly in version 1.4 (bug #192)
- New clustering licence model fully supported. (bug #193)
- Bug #168: The Wallboard and Licence pages would not compile on some containers
- Bug #169: Zero-second connect times now allowed in the realtime page
- Bug #176: Tables now appear correctly aligned in Firefox
- Bug #160: Custom reports buttons have been swapped back to their pre-1.4 positions. Sorry guys.
- Bug #175: Sometimes agents would not be assigned to the correct level in the Agent Sessions page.
- Bug #179: Qloaderd ingnores HEARTBEAT records when deciding where to start uploading data.
- Bug #183: Multiple page encoding - a very rare bug - solved.
- Bug #184: The channel name normalizer was sometimes too eager to chop off channel data to get the channel name.
- Bug #106: Check if a file can be streamed and output an error message if it cannot.
- Bug #159: The database update tool for 1.4.0 would crash if an index was missing.
- Bug #177: The login page will now auto-focus on loading to the input field.
- Bug #187: Malformed RINGNOANSWER / AGENTATTEMPT series could cause QM to crash.


The website will be upgraded in a few hours, but it's already available for yum users. See http://queuemetrics.com/download.jsp

[rjch]

I noticed in upgrading from 1.4.0 to 1.4.1 that QueueMetrics started complaining about running a cluster of 2 nodes as being more than that allowed by the free license.  Whilst we run 2 Asterisk servers, only one is ever active at a time (the other is either a hot-backup or being used to put upgrades through testing before going in to production) and our call centre only has 2 or 3 agents at any one time.

I understand and accept that we can not run reports for those times when 3 agents are logged in, however the change to restrict us to one Asterisk server was both unexpected and a little inconvenient.  Was this new restriction intended?  If so, it would perhaps be in your best interest to make it clear up-front to ensure that others don't run into the same surprise that I did.

[QueueMetrics]

If that is your setup, you can simply set up two different instances of QM (free version) to monitor each box separately. While all older QueueMetrics versions were single-server (1 QM for 1 Asterisk), QM 1.4 included a free but time-expiring clustering mode. From 1.4.1 onwards, this should be purchased if needed.
I am sorry if this was not very clear - we are revisng the licence page and will surely make it clearer there. Thanks for pointing that out.

[rjch]

If that is your setup, you can simply set up two different instances of QM (free version) to monitor each box separately. While all older QueueMetrics versions were single-server (1 QM for 1 Asterisk), QM 1.4 included a free but time-expiring clustering mode. From 1.4.1 onwards, this should be purchased if needed.
I am sorry if this was not very clear - we are revisng the licence page and will surely make it clearer there. Thanks for pointing that out.

The reason I chose to set up the "clustered" implementation as opposed to two separate installations was to allow us to retain historical information from both servers, regardless of which one was active at the time.

Please don't think I'm unhappy about the restriction - for a free version of commercial software, I wouldn't expect it to support clustering - my only concern was that I was caught by surprise when upgrading and was hoping to make sure others don't get caught the same way.  Hopefully now I'll have a little more leverage with management to get the funding cut loose!