vicidial.org

This one includes some fixups to the dynamic portal and apache config files. I've also added certbot and ViciBox Firewall instructions to the install manual.\

So whoever feels like giving feedback AFTER installing vicibox v.9.0 here are the links:

http://download.vicidial.com/iso/vicibo ... -beta2.iso
http://download.vicidial.com/iso/vicibo ... nstall.odt



I'm about 3/4 of the way done with my testing but I'm sure I missed something. Asterisk 11 still looks like it's dead unless someone else wants to take a crack at trying to get it to compile on OpenSuSE v.15.1.

Still have to go through the certbot script again and a few other things.

We've been running it in dev for a few days, and are having some issues. Could be as a result of configuration errors, however, so take it with a grain of salt:

Time doesn't seem to be updating correctly. We're GMT+10, and when running reports for the last couple of days worth of calling we don't get the correct calls on the correct days. I'd wager it's reporting us as GMT and not moving.
Callbacks appear to be flagging strangely. Callbacks booked for some leads are flagging different leads that don't exist, in lists that don't exist.

Again, could be configuration errors, but I've updated the timezone wherever I can find it, and can't find any configuration that would cause the callbacks to record against a different lead.

I'm going to keep digging over the weekend to see what configs could be out, and I am going to run some zypper updates to see if that's causing the issues, but our other installs of 8-point-whatever don't seem to be having these issues.

What information do you need to shed more light here?

Go to the "Reports" web page, then in the SERVERS table at the bottom of the page click on the plus sign "+" next to "SERVERS", and post the times that show up for each line in that table.

Also there might be some lingering PHP7 issues with ViciDial. We've already gone through and fixed some things. What SVN code base are you running against?

mflorell wrote:Go to the "Reports" web page, then in the SERVERS table at the bottom of the page click on the plus sign "+" next to "SERVERS", and post the times that show up for each line in that table.

All 3 are the same time. Updating correctly for our timezone. I should probably call out that I had to manually update the PHP time to get the correct time display in the admin interface.

Kumba wrote:Also there might be some lingering PHP7 issues with ViciDial. We've already gone through and fixed some things. What SVN code base are you running against?

3129 according to the servers report from above. Haven't updated Zypper yet, or done any digging around, but that's on the list for today. As is an update from SVN trunk.

A potential PHP issue would explain the lists/callbacks issue I guess. I'm not a developer, though - I'm in callcenter.

We've run about a thousand calls through it this week so far. Is there any other info that would be helpful?

looks like something is buggy with phone aliases

when I try to login with any user that has a phone alias it throws this error

Sorry, there are no available sessions: ||||/|

I changed the time zone in both php.ini's on my webserver and rebooted it.. seems like it fixed it

kashinc wrote:I changed the time zone in both php.ini's on my webserver and rebooted it.. seems like it fixed it

Good postback!

I am more than willing to work someone and get this running in a production environment however I would need fixes and updates to happen pretty quickly as this is installed on an extra cluster configured in an extra rack I have.

So far everything looks ok but I have noticed a new bug in the Bulk DID groups, They don't seem to insert numbers into the groups, instead it has some bug that creates a bunch of DID groups that are two digits that are empty and then cant be deleted after.

If anyone wants to work with me on this beta and help report all the bugs, I am sure we could reach a stable release of version 9 much quicker.

-kashinc

Updates to the callback issue:

Updated both php.ini timezones to be correct. I have not done more reporting tests to see if that has resolved the issue yet.

Updated the server to latest SVN using the following process:
svn up (in trunk dir) to 3130
perl install.pl (per viewtopic.php?t=16326)

Performed all available zypper updates (which included at least one php7 module)

The issue persists. Callbacks are not displaying the right lead information.

They reflect the right date and time in the list, and the call date/time seems to be right.
Under the INFO column, it appears to show the start of the notes entered.
The phone number also appears to be correct, but I need to do some more testing to verify (all our test leads have the same phone number - although I don't believe the leads in list 101 have been changed from the default).

However:
The First Name is 'Matt' (test lead)
The Last Name is Lead07 (from the test lead)
When pressing for lead info, it shows Lead07 from list 101, none of the notes/comments or callback notes, and the information is for Lead07.

Hope this helps. It just seems to be associating the callback with the wrong lead. Possibly the callback script is not correctly updating the database as to which lead it should be for. Could this be permissions of some kind?

Let me know if I can shed any more light. My next test is to restore this database to a dev system on the old version (8-point-whatever) and see if the issue persists.

All closers are seeing 5 calls in que, No calls are currently in que.

The Status Groups are not working correctly either, the page that shows the Status Groups shows a broken 1 Char status group. I did update to the latest SVN this morning SVN:3131

seems that whitelist/blacklist dynaportal also is throwing an error. it lets me add the IP into the portal but does not whitelist anything.

[Tue Aug 27 20:13:46.212555 2019] [php7:error] [pid 16232] [client 174.72.XXX.XXX:57430] PHP Fatal error: Uncaught Error: Call to a member function bind_param() on bool in /srv/www/vhosts/dynportal/inc/functions.inc.php:65\nStack trace:\n#0 /srv/www/vhosts/dynportal/valid8.php(125): getphonelogin('z1025')\n#1 {main}\n thrown in /srv/www/vhosts/dynportal/inc/functions.inc.php on line 65, referer: https://server.com:446/valid8.php

For the admin web issues in PHP7.2(including VICIbox 9) we have just committed several fixes to svn/trunk, so please upgrade to the latest svn/trunk and test again.

Thanks!

kashinc wrote:seems that whitelist/blacklist dynaportal also is throwing an error. it lets me add the IP into the portal but does not whitelist anything.

[Tue Aug 27 20:13:46.212555 2019] [php7:error] [pid 16232] [client 174.72.XXX.XXX:57430] PHP Fatal error: Uncaught Error: Call to a member function bind_param() on bool in /srv/www/vhosts/dynportal/inc/functions.inc.php:65\nStack trace:\n#0 /srv/www/vhosts/dynportal/valid8.php(125): getphonelogin('z1025')\n#1 {main}\n thrown in /srv/www/vhosts/dynportal/inc/functions.inc.php on line 65, referer: https://server.com:446/valid8.php

Found and corrected. It was a sloppy mash up of two different version of how this function played out when I was testing case sensitivity. But anyways, It's been fixed in the code now and will be in the next release.

To fix this change the 'getphonelogin' function in /srv/www/vhosts/dynportal/inc/functions.inc.php to this:

Code: Select all

function getphonelogin($user) {
        global $dbVICI;
        $phonelogin='';
        $phonepass='';
        $sql_ending='limit 1;'; # Default non-case sensitive sql ending
        if ($PORTAL_casesensitive>=2) { $sql_ending='limit 1 COLLATE utf8_bin';}
        $phonestmt = $dbVICI->prepare("select phone_login, phone_pass, $PORTAL_adminfield from vicidial_users where user=? $sql_ending;");
        $phonestmt->bind_param('s', $user);
        $phonestmt->execute();
        $phonestmt->bind_result($phonelogin, $phonepass, $adminfield);
        $phonestmt->fetch();
        $phonestmt->close();
        return array($phonelogin, $phonepass, $adminfield);
}


Closer to release ...

I believe I have the last of the bugs ironed out. I'll run through my cluster tests again tomorrow and clean up a few things in the documentation and I think it shall be released this weekend.

So far my technician who tested it only complains that his VM required extra memory to avoid asterisk crashes AND ... "I have no control over the OS during the install!" He likes to choose drive formatting and layout options. I, however, do not. I prefer avoiding LVM at all costs, but other than that I like to use the "by design, tested by thousands of users" settings when possible.