vicidial.org

We just posted 2.2.0 RC 5 to sourceforge

https://sourceforge.net/projects/astguiclient/files/


Please test it out if you can and we should be able to do a full release in the next few days.


There are several bug fixes, a couple report additions and most of the reports have had a popup calendar added to select the dates.

Here is a list of the rest of the changes since 2.0.5:

http://www.vicidial.org/VICIDIALforum/v ... php?t=9854

any changes on the agent screen? cos we have customized the form fields

hi mflorell i have see the add of the calendar in your new rc5
he is tigra calendar ,can we replace this calendar data picker to the default calendar od callback in the agent interface.

Yes there have been a few changes to the vicidial.php script.

As for the callback calendar in the agent interface, I might change that in SVN trunk, but not in the 2.2.0 branch.

ok thanks when you put it in the svn say us it
thanks

Quick 2 part question about the new Log Table Rotators in the new version.

Added log rolling archive script to automatically move logs into archive tables monthly

Will this cause the vicidial_log history and agent_log history to no longer be available on the lead modification screen if I activate this process?

The reason I'm asking is because we have collections leads in our system that may be called for months on end and having access to the complete history is important in our model.

Also... The first time this process runs, should it be done manually to avoid conflicting with other processes due to the time it would take to run through the 1.3 million records?

That is correct, you would no longer see those calls on your history when you go to the lead modification page. The log rolling script is commented out by default, so you have to enable it for it to run.

cos we have customized the form fields

Any chance of sharing the code with the Community ?

Any chance of sharing the code with the Community ?

customized means instead of using address2 we changed it to URL. we changed the name of the fields to what ever we wanted .

Do you want that?

That is correct, you would no longer see those calls on your history when you go to the lead modification page. The log rolling script is commented out by default, so you have to enable it for it to run.

Matt, will it be possible to create another table on vicidial and have it logged everytime the log rolling script runs? This way when you check the history of a lead the php script will also check the archive log?

I'm sure you could add something to do that, but on systems with 200,000,000+ calls in the logs(and we do have clients like this) that could result in the script taking a REALLY long time to run.

Geil21 wrote:Quick 2 part question about the new Log Table Rotators in the new version.

Added log rolling archive script to automatically move logs into archive tables monthly

Will this cause the vicidial_log history and agent_log history to no longer be available on the lead modification screen if I activate this process?

The reason I'm asking is because we have collections leads in our system that may be called for months on end and having access to the complete history is important in our model.

Also... The first time this process runs, should it be done manually to avoid conflicting with other processes due to the time it would take to run through the 1.3 million records?

It maybe useful to add for future reference that script could be easily adjusted how many months old records are being moved:

Code: Select all

...
#change 2 to how many months old records to be moved and deleted
$mon = ($mon - 2);
...

Thank you for all of that.

One last question re: rc5

I am upgrading production to RC5 this weekend.

If the new features freak out the managers and reps (they hate change) will I be able to roll it back while keeping the new database structure or will I have to do a complete restore and loose any changed statuses?

Or to put it another way.. Is the new database structure compatible with older versions?

I have not tested the new DB schema with old code. It might work, but there could be some corruption of log data while you are running like that.

Alright, Thank You for letting me know.

I'll just make sure that the changes to the database can be reversed in the event of a roll back as part of my contingency plan and If not then I'll write a rollback transformation process that can rebuild the original structure and transform the changed records back to that format.

Should be pretty easy to do.

I'm not planning on rolling back but I must be prepared just in case.

If I do write a roll back transformation process I'll share it for ya

Thanks Again for everything Matt,
Glenn

There are many companies that have been using 2.2.0 for several weeks so there shouldn't be any problems. The ADMIN_backup.pl script should help with your snapshot of the DB and web/perl scripts.

Thanks for the great work.

I went through the bugs in Mantis again after the release of rc5. I had registered 34 bugs or feature requests in the 2.2 development cycle, and most of the issues have been fixed, and most of the new features that I have proposed have been included. Seems like the following are the only outstanding issues that still remain:

http://www.vicidial.org/VICIDIALmantis/view.php?id=304
Pause time accounting in Agent Log is broken for Manual Alternate Dialing. The pause time exhibits huge jumps at each time an alternate number is dialed.

http://www.vicidial.org/VICIDIALmantis/view.php?id=300
Seems like there are still some issues in Agent Reports, but I have to do more testing on this one to isolate the bugs.

http://www.vicidial.org/VICIDIALmantis/view.php?id=289
I will do some more testing on this issue, but it seems like this one can affect auto-dialing on SIP Trunks.

I will do some more testing on issues 289 and 300 next week to see if I can isolate the problems.

just a quick FYI

the link in the scratch install document does not work

wget http://internap.dl.sourceforge.net/sour ... _2.2.0.zip
--15:12:06-- http://internap.dl.sourceforge.net/sour ... _2.2.0.zip
=> `astguiclient_2.2.0.zip'
Resolving internap.dl.sourceforge.net... 69.88.152.3
Connecting to internap.dl.sourceforge.net|69.88.152.3|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: http://prdownloads.sourceforge.net/astg ... eforge.net [following]
--15:12:06-- http://prdownloads.sourceforge.net/astg ... eforge.net
=> `astguiclient_2.2.0.zip?download&failedmirror=internap.dl.sourceforge.net'
Resolving prdownloads.sourceforge.net... 216.34.181.59
Connecting to prdownloads.sourceforge.net|216.34.181.59|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
15:12:06 ERROR 404: Not Found.

Is there a difference in how permissions are handled in 2.2?

I have updated astguiclient but have not updated the database yet and I no longer have permission to view most of the pages.

Hopefully once I update the DB permissions will come back

You should update the DB before updating the scripts(doing the install.pl)

There are a lot of changes in the back-end database that might cause you not to have access if you have not done the DB updates.

ok, i was following the upgrade doc that has the scripts first. I have a while before my DB backup is complete so I was just trying to see some of the changes while waiting for the backup.

I guess that confirms my earlier question about backwards compatability =)

Thanks Matt

I assume from the changes doc that this version is completely DAHDI compatible?

Yes, we have tested with DAHDI and our testing and development platform is running DAHDI with T1 cards.