Automate Lists

[Bentfinger]

Is there a way to automate lists to turn on/off at designated times of the day?
V.8 2.14-531c BUILD: 170808-1014
Thanks,

Bentfinger

[blackbird2306]

This is not a feature yet, but you can achieve this by putting 2 lines into your crontab (linux cli: crontab -e):
E.g. activate testlistid1 and testlistid2 at 8 (am) o'clock in the morning and deactivate same lists at 8 (pm) o'clock in the evening

Code: Select all

0 8 * * * mysql -D asterisk -e 'UPDATE `vicidial_lists` SET active = "Y" WHERE `list_id` IN ("testlistid1","testlistid2");'


Code: Select all

0 20 * * * mysql -D asterisk -e 'UPDATE `vicidial_lists` SET active = "N" WHERE `list_id` IN ("testlistid1","testlistid2");'


Just replace "testlistid1","testlistid2" with your own list_ids: IN ("id1","id2","id3","and_so_on")
and edit your own activation/deactivation times!

[williamconley]

1) Good job listing your specs.

2) If your concern is the time zone of the recipients, that's what "Local Call Time" is designed for. You can create a local call time which will apply to an entire campaign and allow calling at the Recipients Time. For instance: If you create a "Call Time" of 3PM to 6PM and apply that as the "Local call time" on the campaign, calls will be generated to californians at 3PM to 6PM PST and to Floridians at 3PM to 6PM EST. NO coding required.

3) It's fairly simple to write a mysql query to activate and/or deactivate a list. Bash scripts, perls scripts, and php scripts can all push the sql query into the server. PHP scripts have the added advantage of being accessible through Web if located and coded properly. Automation then can be handled through "crontab" in the OS or through any external system capable of pulling the web page (if PHP based).

4) Do note that deactivating a list through mysql will also require clearing leads from the hopper that are in that list (and not already queued). If you deactivate a list in the web interface, this is done for you, but if you're using mysql directly ... self-service time.

Happy Hunting!

[blackbird2306]

4) Do note that deactivating a list through mysql will also require clearing leads from the hopper that are in that list (and not already queued). If you deactivate a list in the web interface, this is done for you, but if you're using mysql directly ... self-service time.

No you are not right. Deactivating a list from web interface won't clear anything. It is sufficient to deactivate the list directly by mysql and it makes no difference to web interface. The hopper script will clear the leads automatically at least after 1 minute regardless of how you deactivated them. The decisive point is only mysql active status!

[williamconley]

4) Do note that deactivating a list through mysql will also require clearing leads from the hopper that are in that list (and not already queued). If you deactivate a list in the web interface, this is done for you, but if you're using mysql directly ... self-service time.

No you are not right. Deactivating a list from web interface won't clear anything. It is sufficient to deactivate the list directly by mysql and it makes no difference to web interface. The hopper script will clear the leads automatically at least after 1 minute regardless of how you deactivated them. The decisive point is only mysql active status!

Care to place a wager?

It is usually sufficient, based on empirical evidence, that just deactivating the list is sufficient. Just like the brakes on your car, however: You push the pedal, the car stops. Every time you push the pedal. But what if a brake line pops? Suddenly that stops working. One in a million, right?

Well: What if this lead gets pulled during those 60 seconds? Doesn't that pretty much defeat the purpose of deactivating the list? What if the version of Vici you have doesn't qualify leads before dialing them or dump them from the hopper at the 60 second mark? (What if your configuration allows dialing of leads in the hopper without checking, there are configuration options on point)?

My opinion: Skip all those risks and lose the leads from the hopper if it's important to you that these leads not be dialed. Just don't delete them if they are already being dialed as that, too, could cause a freaky break.

Also, when you move a list to another campaign, the Vicidial Web Interface will clear the hopper to avoid freaky collisions from the wrong campaign ID on the lead vs the hopper. While arcane, those problems could cause odd logging and handling issues which are best avoided. The same could be said for dialing a lead in an inactive list. I prefer NOT to wait for someone to find out why that was a bad idea. It's free to fix now. One extra query and no risk.

Unless you just love trouble.

[blackbird2306]

I don't recommend to force a reset of the hopper, unless it is strictly necessary. For instance the need to stop immediately the dialing of this list without a waiting period of max 60 seconds. Playing with the hopper by resetting it often mess up the order of anyone callbacks and lead recycling and most importantly it disrupts the "Auto Alt-Number Dialing" process. Another crucial thing, you have to weigh what's more acceptable: Not dialing any leads for up to 60 seconds (long working time in a call center with 300 seats!!) or dialing the deactivated list up to 60 seconds ! I don't like it, but sure you can do this also by putting it into your crontab (change according to your deactivation time with a small sleep e.g. 3 seconds):
this is the official query vicidial uses for wiping the hopper on a campaign basis:

Code: Select all

0 20 * * * sleep 3; mysql -D asterisk -e 'DELETE from vicidial_hopper WHERE `campaign_id` IN ("campaignid1");'


perhaps this one is better on a list_id basis, which could avoid the dialing break (I didn't verify if it is OK to delete only a part of the hopper):

Code: Select all

0 20 * * * sleep 3; mysql -D asterisk -e 'DELETE from vicidial_hopper WHERE `list_id` IN ("testlistid1","testlistid2");'


Conclusion: no difference in deactivating lists with web interface or directly through mysql. Only reset the hopper, when there is need to stop immediately dialing these lists. This applies to web interface deactivating also!

[williamconley]

... force a reset of the hopper, ...

clearing leads from the hopper that are in that list (and not already queued).

These are not the same thing. Technical notes are technical. You changed the statement to one of your own, then argued with the changed statement. Tsk.

[blackbird2306]

You always have to have the last word, and you always think you are right. This seems to be your character a know-it-all. And don't bump in my posts again, it would be a nice hobby to do this as well all the day with your posts.
For a better understanding: You mean deactivating a list from web interface is OK without clearing the hopper, but deactivating in mysql directly (which is same process what I had to teach you) needs a special query to clear the hopper? How about saying sorry I thought deactivating from web interface would clear the hopper, but I wasn't right? But instead you try to mop up me with things like tsk...

[williamconley]

You always have to have the last word, and you always think you are right. This seems to be your character a know-it-all. And don't bump in my posts again, it would be a nice hobby to do this as well all the day with your posts.
For a better understanding: You mean deactivating a list from web interface is OK without clearing the hopper, but deactivating in mysql directly (which is same process what I had to teach you) needs a special query to clear the hopper? How about saying sorry I thought deactivating from web interface would clear the hopper, but I wasn't right? But instead you try to mop up me with things like tsk...

Or what I said which was:

Well: What if this lead gets pulled during those 60 seconds? Doesn't that pretty much defeat the purpose of deactivating the list?

But you go ahead and make up stuff I said and attribute it to me instead of what I actually said, then argue with the statement you made instead of the one I made. All while acting like someone else's post is your territory. Interesting standpoint.

Not like I was trying to help or offering technical advice, and enhancing your answer (and allowing the original poster to decide which way to go with as much information as possible). If the poster wants to deactivate the list and take the chance that some of those leads will be dialed after, that's kinda up to them, isn't it?

That's why I phrased my statement the way I did. Not "Don't do it!" or "Do it!", but purpose-based.

Funny: I don't see anywhere on my posts where I told someone else NOT to chime in. Even when they get downright craxxy. Maybe because I'm just here to help.

[Bentfinger]

Thanks Blackbird and Bill. The activation times will be for a separate list within the campaign, so I will use the solution presented first, as it will fit my needs. There will be other lists within that campaign, and the difference of 60 seconds (or even dialing the rest of the leads from that list that are in the hopper, as this is a small room) will not make an impact. But all the other information was and will be helpful as well. It has been a few years since I have had the pleasure of using Vici, I am happy to be back.

[Bentfinger]

as an after thought, and I apologize for my ignorance as I am new to sql, I have mostly used the API to make changes, but can I adjust the code to clear the hopper of the leads from the deactivated lists 1 minute after deactivating the lists ie: 8:00 to deactivate and 8:01 to clear the hopper?

[williamconley]

as an after thought, and I apologize for my ignorance as I am new to sql, I have mostly used the API to make changes, but can I adjust the code to clear the hopper of the leads from the deactivated lists 1 minute after deactivating the lists ie: 8:00 to deactivate and 8:01 to clear the hopper?

You can do it any time you like, but why would you wait a minute before taking these leads out of the hopper? If the goal is to stop them from being dialed ...

However: If you want to wait a minute, there's no rule says you can't. It's your dialer.

[mflorell]

We've used the AST_settings_container_SQL.pl script and Settings Container entries with crontab entries to do similar tasks to what you describe with SQL on a scheduled basis on many client systems.

[Bentfinger]

Thanks, yes the goal is to stop them from being dialed, but it is not vital, so I was putting it out 1 minute just so the dialer was not doing them at the same time. I found the correct time format as 7 for 7:00, 01 7 for 7:01. This is getting fun, thanks again Matt and Bill.