Issues not applying submitted settings

[techbob]

Hello to everyone, I hope somebody can help me with the following problem:

I did a fresh install of VICIDial on a Debian (Squeeze) machine and everything seems to work fine, I had MySQL upgraded to 5.6 running the db. Set the global sql_mode to an empty string so as not to have issues with the DB erroring out which it used to do on another installation. The GUI seems to work fine until I change Allow Inbound then it curiously does not even apply the setting I changed when the admin page reloads.

To prevent any actual issues from the db I completely discarded the old db and started from scratch the issue doesn't go away. It was the original reason why I upgraded to MySQL 5.6.26 from 5.1 then downgraded to 5.6.23 so I could copy the db from another working server with the same SVN revision and db schema and MySQL version.

On investigating I copied the SQL statement from the admin changes listing as-is and it seems to error out with the following warning, if I manually set the Allow Inbound setting to Y it works just fine. I just can't figure out why it's doing this. I tried running the statement both as root and as the cron user via cli and it still seems to do the same thing, I had this issue before and somehow fixed it by using an sql dump from another server I had running with the same db schema but using just the structure, this time it's a no-go.

mysql> show warnings;
+---------+------+---------------------------------------------------------------+
| Level | Code | Message |
+---------+------+---------------------------------------------------------------+
| Warning | 1265 | Data truncated for column 'agent_select_territories' at row 1 |
+---------+------+---------------------------------------------------------------+
1 row in set (0.00 sec)

[techbob]

Additionally,

My PHP version is (5.3.3-7+squeeze19) not sure if it's what's causing he issue to present itself.

[techbob]

It seems to be a bug of some sort. I just can't tell though. After DISABLING the campaign then setting the aforementioned field to Y, it seems to work fine as if there was no issue at all. Might have been how it resolved in another server I was working on.

Additionally, is it just me? The settings in the

Code: Select all

astguiclient.conf

file -- setting db address to

Code: Select all

VARDB_server => localhost

seems to break the perl scripts and needs to be set to

Code: Select all

VARDB_server => 127.0.0.1

or some IP address.

[mflorell]

We have seen this issue before a few times on non-vicibox systems. It is always better to specify an IP address instead of forcing a name lookup that some components can have problems with.