Author Topic: agent URL Screenpops not working when using SQL backend  (Read 2765 times)

bluegrass

  • Newbie
  • *
  • Posts: 3
  • Karma: 1
    • View Profile
    • Email
I am running QueueMetrics 1.4.3 on a CentOS 5.1 server. Queuemetrics and asterisk reside on the same server. The original installation was performed via the yum install method and queuemetrics has been functioning for several months. Recently the customer requested that we implement popups for a custom url for the agents to integrate with their custom CRM. This is when my problems began.

I just spent the last several hours tracking down why URLs werent working with QueueMetrics when the SQL was the backend. The documentation claims that to support URLs one merely needs to populate the Queue command in extensions.conf like so:

Code: [Select]
Exten => s,7,Queue(myqueue|nt|http://mysite/app?clid={$CALLERID}||60)
I discovered that despite queue_log getting populated correctly, the URL was always truncated in the Agents live screen.

After much digging through qloaderd.pl and other sources I finally identified the error in the mysql schema the database is constructed with.

Why on earth is column data1 a varchar(30) ?????

I altered table to modify the column to varchar(255) which seems to resolve the issue for me. I have another installation that was 1.4.3 that i upgraded to 1.4.4 via yum update and its data1 column also appears to be a varchar(30).


QueueMetrics

  • Loway
  • Hero Member
  • *
  • Posts: 2999
  • Karma: 39
    • View Profile
    • QueueMetrics
Re: agent URL Screenpops not working when using SQL backend
« Reply #1 on: June 23, 2008, 16:53:19 »
Cool. This is correct.  ;D
We'll fix that for 1.4.5 (bug #416).

QueueMetrics

  • Loway
  • Hero Member
  • *
  • Posts: 2999
  • Karma: 39
    • View Profile
    • QueueMetrics
Re: agent URL Screenpops not working when using SQL backend
« Reply #2 on: September 26, 2008, 15:49:11 »

I altered table to modify the column to varchar(255) which seems to resolve the issue for me. I have another installation that was 1.4.3 that i upgraded to 1.4.4 via yum update and its data1 column also appears to be a varchar(30).



This has been fixed in the upcoming release 1.5.0.