vicidial.org

Hi All,

I have some issues with a seemingly failed upgrade from vicidial version v.3.1.15 to a newer version. So, we updated the database using all the scripts from upgrade_2.8.sql to the current upgrade_2.14.sql. No issues there and no corruption on any tables.

Then we upgraded the frontends using the subversion method and no issues there either. Asterisk starts, vicidial service running, however the agents are unable to get leads on manual dial (we only do manual dial), there are definitely leads in the tables as confirmed by looking in the campaign page. Agents CAN dial their callbacks, but when logging into a campaign normally and wanting to dial the next lead we are greeted with either "No more leads in the hopper for campaign" or "call was not placed, there was an error: CALL NOT PLACED Conf Exten 8600073 or campaign XXXXX or ext_context default or phone_number or lead_id is not valid "

depending on how the campaign is configured. If the agent selected to preview the lead they note "STATUS: Calling: ()- Lead: Preview the Lead then DIAL LEAD" at the top of the screen, clearly indicating that there is an issue.

Server versions all look good,

Code: Select all

SERVER   DESCRIPTION   IP   ACT   LOAD   CHAN   DISK   TIME   VER
dial301   Server dial301   192.168.0.96   Y   0 - 1%   0   1%   2017-07-17 10:13:41   2792
    /usr/src/astguiclient/trunk
Path: .
Working Copy Root Path: /usr/src/astguiclient/trunk
URL: svn://svn.eflo.net/agc_2-X/trunk
Relative URL: ^/agc_2-X/trunk
Repository Root: svn://svn.eflo.net
Repository UUID: 3d104415-ff17-0410-8863-d5cf3c621b8a
Revision: 2792
Node Kind: directory
Schedule: normal
Last Changed Author: mattf
Last Changed Rev: 2792
Last Changed Date: 2017-07-12 21:49:48 +0200 (Wed, 12 Jul 2017)


vicidb02   Database Only- DO NOT DELETE   192.168.0.246   Y   0 - 100%   0   1%       0
    /usr/src/astguiclient/trunk
vicife03   Asterisk 03   192.168.0.92   Y   13 - 3%   65   33%   2017-07-17 10:13:41   2793
    /usr/src/astguiclient/trunk
Path: .
URL: svn://svn.eflo.net:3690/agc_2-X/trunk
Repository Root: svn://svn.eflo.net:3690
Repository UUID: 3d104415-ff17-0410-8863-d5cf3c621b8a
Revision: 2793
Node Kind: directory
Schedule: normal
Last Changed Author: mattf
Last Changed Rev: 2793
Last Changed Date: 2017-07-14 05:14:10 +0200 (Fri, 14 Jul 2017)


vicife07   Asterisk 07   192.168.0.87   Y   52 - 19%   78   34%   2017-07-17 10:13:41   2793
    /usr/src/astguiclient/trunk
Path: .
URL: svn://svn.eflo.net:3690/agc_2-X/trunk
Repository Root: svn://svn.eflo.net:3690
Repository UUID: 3d104415-ff17-0410-8863-d5cf3c621b8a
Revision: 2793
Node Kind: directory
Schedule: normal
Last Changed Author: mattf
Last Changed Rev: 2793
Last Changed Date: 2017-07-14 05:14:10 +0200 (Fri, 14 Jul 2017)





And the servers indicate "VERSION: 2.14-620a BUILD: 170623-2142"

Am I missing something obvious?

There is no vicidial version v.3.1.15, since Vicidial is still in the 2.X versions. Do you know the admin version and build you used to be on? And the DB schema version you were on before?

Have you looked at your apache error_log file?

Sorry Matt, you're correct. It was the version from the installer Vicibox redux v.3.1.15 that you see when logging in.

Database version was 1355 before upgrade. I've grabbed admin version 2.8-408a, build 130711-2208 and overwritten the agc directory. Agents seem to be able to work normally now, but I would like to have them working on the latest interface.

Apache error log shows a lot of these:

Code: Select all

[Mon Jul 17 09:31:27 2017] [error] [client 192.168.0.89] PHP Warning:  mysqli_num_rows() expects parameter 1 to be mysqli_result, boolean given in /srv/www/htdocs/vicidial/functions.php on line 47, referer: http://192.168.0.87/vicidial/realtime_report.php?RR=4&DB=0&group=Getit
[Mon Jul 17 09:31:27 2017] [error] [client 192.168.0.89] PHP Warning:  mysqli_fetch_row() expects parameter 1 to be mysqli_result, boolean given in /srv/www/htdocs/vicidial/AST_timeonVDADall.php on line 1772, referer: http://192.168.0.87/vicidial/realtime_report.php?RR=4&DB=0&group=Getit
[Mon Jul 17 09:31:27 2017] [error] [client 192.168.0.89] PHP Warning:  mysqli_fetch_row() expects parameter 1 to be mysqli_result, boolean given in /srv/www/htdocs/vicidial/AST_timeonVDADall.php on line 1806, referer: http://192.168.0.87/vicidial/realtime_report.php?RR=4&DB=0&group=Getit


Look for the queries directly above the lines mentioned in those log entries:

/srv/www/htdocs/vicidial/functions.php on line 47
/srv/www/htdocs/vicidial/AST_timeonVDADall.php on line 1772
/srv/www/htdocs/vicidial/AST_timeonVDADall.php on line 1806

Then try running those queries in the MySQL command line(you might have to use dummy date/etc for them to run).

Usually the issue is missing fields in the database because some of the upgrade SQL file statements were either not run or errored out for some reason.

Seems to be some differences on fields in the vicidial_list table

working cluster - `modify_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
versus - `modify_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,

working cluster - `middle_initial` varchar(1) COLLATE utf8_unicode_ci DEFAULT NULL,
versus - `middle_initial` varchar(5) COLLATE utf8_unicode_ci DEFAULT NULL,

working cluster - `state` varchar(2) COLLATE utf8_unicode_ci DEFAULT NULL,
versus - `state` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,

working cluster - `owner` varchar(20) COLLATE utf8_unicode_ci DEFAULT '',
versus - `owner` varchar(20) CHARACTER SET utf8 DEFAULT '',

Could it be the utf8_unicode_ci instead of utf8?

Made some progress here.

Examining the system_settings table between a working server and the "problem" indicates that there are differences in the following fields:
allow_custom_dialplan - was set to 0 on the non-working cluster, and set to 1 on a working cluster. Changed to 1.
default_voicemail_timezone was not populated with all the options, copied these across from a working cluster as well.

Agent screen successfully allows the agent to pull up new leads and dial. Pretty sure there's more fallout to be expected, but at least we have a dialling cluster.