Messages

121

QueueMetrics installation / Re: No queues found. Check your datasource validity

« on: May 25, 2009, 10:01:48 »

Hi.
Thank you for your configuration files snapshot.
I've investigated to the problem and I can confirm that is related to an issue raised by the Wizard that's filtering all queues with no member specified. The bug will be fixed in the next QueueMetrics coming release.
To overcome to this problem, actually you can manually add a dummy member in each queue definition. You can do it from the TrixBox GUI or, manually, adding a line similar to:

member=Agent/0000

on each queue definition defined in the file queues_additional.conf
You should have something like that:

[300]
announce-frequency=0
announce-holdtime=no
autofill=no
eventmemberstatus=no
eventwhencalled=no
joinempty=yes
leavewhenempty=no
maxlen=0
monitor-type=mixmonitor
monitor-format=wav
periodic-announce-frequency=0
queue-callswaiting=silence/1
queue-thereare=silence/1
queue-youarenext=silence/1
retry=5
strategy=rrmemory
timeout=15
weight=0
wrapuptime=0
member=Agent/0000

Then you've to start the wizard again.

Thank you for the feedback!
Best regards,

Marco Signorini.

122

Running QueueMetrics / Re: Making Outcome Pop-up window wider

« on: May 07, 2009, 10:05:37 »

Hi,
The bug is actually fixed doubling the dropdown menu width.
It will be delivered on next release that will be ready on few days.

Thank you for your feedback.
Marco.

123

Running QueueMetrics / Re: Is it a bug??

« on: April 24, 2009, 10:59:59 »

Hello,

the "default.showLostCallsWhenFiltering" is an obsolete parameters that was removed in QM 1.5.1.
Starting from this version, when filtering by agent, lost calls were automatically shown only for outgoing calls. Inbound lost calls were not shown when filtering by a specific agent (because being not answered these calls are not associated to any agent).

The QueueMetrics 1.5.1 User Manual reports this key as obsolete and removed on 1.5.1 as you can see in the page 137.

Thank you and best regards,
Marco.

124

Running QueueMetrics / Re: Does QM use the first or last configuration.properties value if there are dups?

« on: April 15, 2009, 09:42:30 »

Hi Andrew,

thank you for the feedback.
I've removed the duplicated entry from the default configuration file.

The new QM release will have this key set to false.


Regards,
Marco.

125

Improving QueueMetrics / Re: WishList: Option to disable per-queue ADDMEMBER/REMOVEMEMBER

« on: April 14, 2009, 15:25:39 »

Hi Andrew.

Actually the "Add Member" and "Remove Member" buttons are implemented listing all the queues associated to a user following this order:

1. All assigned: a composed queue formed by all queues where the agent is working on;
2. All elementary queues where the agent is working on;
3. All other elementary queues visible by the agent.

The idea we had, when we implemented this strategy, was to let able agents to log-in/out to queues not directly assigned to them, for example, to help queues with temporary problems.

Filtering out elementary queues, as asked in your post, requires some modifications in the QueueMetrics code.
We track your suggestion in our feedback tracker as #688 and we plan to implement it in future QueueMetrics releases.

Thank you for your feedback.

Regards,
Marco.

126

Outbound and QueueMetrics / Re: outbound calls

« on: April 09, 2009, 12:12:28 »

Hello.

The callfile.agentdial section is something old and nomore used by QueueMetrics code. We forgot to remove from the default configuration file.
The Dial button present in the Agent page refers to the callfile.customdial section in the configuration file.
Please refer to the link above for the details.

Thank you for your feedback,
Marco.

127

Scripting QueueMetrics / Re: Question on RealtimeDO.RTRiassunto

« on: April 09, 2009, 11:28:04 »

Hi Barry,

I'm trying to replicate the problem you arise but I'm unable to do it. I'm running the PHP code you can find in the QM_XML-RPC_manual_151.pdf (you can download from QueueMetrics support page).
I've modified it a little bit to be able to access to Realtime reports and, for what I can understand, QueueMetrics seems working correctly: if I select more than one queue in the XML RPC query parameters, QueueMetrics is answering with one line for each selected queue plus the "all selected" summary line.
I think that this is the wanted behavior.
I post below the code I'm using; could you, please, test it on your QM revision?
Thank you and best regards.

Marco.

<?php
    require_once 'XML/RPC.php';
   
    $qm_server = "yourmachine"; // the QueueMetrics server address
    $qm_port = "8080"; // the port QueueMetrics is running on
    $qm_webapp = "queuemetrics"; // the webapp name for QueueMetrics
   
    // set which response blocks we are looking for
    $req_blocks = new XML_RPC_Value(array(
        new XML_RPC_Value("RealtimeDO.RTRiassunto"),
        new XML_RPC_Value("RealtimeDO.RTCallsBeingProc"),
        new XML_RPC_Value("RealtimeDO.RTAgentsLoggedIn")
        ), "array");
       
    // general invocation parameters - see the documentation
    $params = array(
        new XML_RPC_Value("200|300"),
        new XML_RPC_Value("robot"),
        new XML_RPC_Value("robot"),
        new XML_RPC_Value(""),
        new XML_RPC_Value(""),
        $req_blocks
        );
       
    $msg = new XML_RPC_Message('QM.realtime', $params);
    $cli = new XML_RPC_Client("/$qm_webapp/xmlrpc.do", $qm_server, $qm_port);
   
    //$cli->setDebug(1);
    $resp = $cli->send($msg);
   
    if (!$resp) {
        echo 'Communication error: ' . $cli->errstr;
        exit;
    }
   
    if ($resp->faultCode()) {
        echo 'Fault Code: ' . $resp->faultCode() . "\n";
        echo 'Fault Reason: ' . $resp->faultString() . "\n";
    } else {
        $val = $resp->value();
        $blocks = XML_RPC_decode($val);

        // now we print out the details....
        printBlock( "result", $blocks );
        printBlock( "RealtimeDO.RTRiassunto", $blocks );
        printBlock( "RealtimeDO.RTCallsBeingProc", $blocks );
        printBlock( "RealtimeDO.RTAgentsLoggedIn", $blocks );
    }
   
    // output a response block as HTML
    function printBlock( $blockname, $blocks ) {
        echo "Response block: $blockname \n";
        $block = $blocks[$blockname];
       
        for ( $r = 0; $r < sizeof( $block ); $r++ ) {
            echo "\n";
            for ( $c = 0; $c < sizeof( $block[$r] ); $c++ ) {
                echo( $block[$r][$c] . "\t" );
            }
        }
    }
?>

128

QueueMetrics installation / Re: realtime.agent_button_4

« on: March 13, 2009, 15:38:30 »

Hi Tony.
The actual agent call button implementation is able to bridge the channel and the extension specified in the configuration file. This is unique and shared to all agents.
We appreciate your suggestion and it will be implemented in next QueueMetrics release.

Thank you for the feedback.
Best regards,
Marco

129

QueueMetrics installation / Re: upgrading to 1.5.1

« on: February 26, 2009, 09:53:34 »

Hi Tonils,
unfortunately in the agent pages there was a different method call compatible only with Java 1.5 and I didn't found it when fixing the call detail pages.

I've replaced it with a 1.4 compatible one and is fixed on build 1286 you can download from the QueueMetrics download page in .tar.gz format.

Thank you again for your feedback.

130

QueueMetrics installation / Re: upgrading to 1.5.1

« on: February 24, 2009, 15:47:33 »

Hi Tonils,
we now have a patch for this issue. You can download it from the QueueMetrics download page in the .tar.gz format.
After installing, please check the build number on the licence page: it should be 1283.
Thank you for your feedback.

Marco.

131

QueueMetrics installation / Re: Pause Status not changing in reports

« on: January 14, 2009, 11:59:27 »

Hi Behnry, I've understood the problem.

I think that you can overcome the problem modifying the dialplan used by QM to schedule pausing/unpausing commands to asterisk.
The idea is to "emulate" an unpausing event in the queue_log file, generated by asterisk and used by QM as datasource, every time that an agent wants to insert a pause code. Being "simulated", the PBX will not be alerted and the agent will not receive any call during the unpause period.

For example, forcing a system echo in order to generate events similar to the listed below log snip could be useful:

1231929752|NONE|NONE|Agent/300|UNPAUSEALL|
1231929752|NONE|200|Agent/300|UNPAUSE|

This could be implemented with lines like that:
exten => 22,n,System( echo "${EPOCH}|NONE|NONE|Agent/${AGENTCODE}|UNPAUSEALL|" >> /var/log/asterisk/queue_log ) in the extensions_queuemetrics.conf file you can find in the asterisk configuration folder.

I did not tried to implement it but I'm feeling it will works. Obviously you'll lose the ability to change mistaken pause codes.

Best regards,
Marco Signorini

132

QueueMetrics installation / Re: Pause Status not changing in reports

« on: January 13, 2009, 15:43:05 »

Hi Bhenry

Looking at your last example, the agent starts the pause with the code "smoke break" for 5 minutes. It then change the pause code (while still paused) using "code meeting". This lasts for two hours.
In the report you should have "code meeting" for 2h and 5 minutes. This is what I'm replicating here and is what I assumed to be the "correct behavior".

To be able to track the list of activities an agent has during the day, the unpause-pause sequence is required instead. This is defined, by design, to let able the agent to correct their pause status in the case he specifies a wrong one by mistake.

In a short way, there are two different cases:
1. The agent wants to correct the last entered pause code: while still paused he pauses again with a different code. QM will overwrite the previous pause code but not the timestamp.
2. The agent wants to specify a new pause code: if in paused status, the agent has to unpause and then pause again with the new pause code.

That's what QM is supposed to behave.

Thank you and bye,
Marco.

133

QueueMetrics installation / Re: Pause Status not changing in reports

« on: January 12, 2009, 11:42:30 »

Hi,
I'm trying to replicate here the problem but I'm not able to do it.

These are the steps I've performed:
1. Log in as agent and set a pause (Launch)
2. Log off as agent
3. Log in as administrator and start a daily report. In the agent pause details report I can see the agent with the associated pause code at time HH:mm:ss
4. Log off as administrator
5. Log in as agent and set a new pause code (I tried with the default one, for example "backoffice", then I've repeated the complete procedure with a custom one "filing")
6. Log off as agent
7. Log in as administrator and start a daily report. In the agent pause details report I can see the agent with the new associated pause code, but the time is referring to the "first" pause event (as reported by the step 3).

For me this is the correct behavior.
If you are able to replicate the problem in a different way, please let me know that I'll investigate about.

Thank you and bye,

Marco

134

QueueMetrics installation / Re: Upgrade from 1.4.4 to 1.4.7 problem

« on: December 05, 2008, 10:31:21 »

Hi,
I've investigated a little bit more about the problem you reported.
Inside the tar file you sent us there are two different QM releases mixed together, probably as a result of an uncompleted upgrade procedure. This, for sure causes not only the problem you signal here, but more subtle problems that are not easy to understand and find.

I strongly suggest you to have a complete reinstall of QM, deleting the version you have not and installing the 1.5.0 already released.

Please, don't forget to backup the database and your custom configuration files (web.xml and configuration.properties) in order to apply to the new installation the key values you changed for customizing your QM copy.

Let me know what you'll have.

Thank you.
Marco Signorini.

135

QueueMetrics installation / Re: Upgrade from 1.4.4 to 1.4.7 problem

« on: December 04, 2008, 18:19:44 »

Hi.
I've replicated the problem on our servers with the installation files you provided. Thank you!
I can confirm that the fix will be ready for the QM 1.5.0 that will be released in few days.

Thank you for the feedback.

Marco Signorini.