vicidial.org

I was curious if anyone had some useful settings containers they use that they wouldnt mind sharing?

I've got about 60 of them on my dev box, there are dozens of uses for Settings Containers, what kind are you looking for?

Didnt have anything particular in mind, never used them before so I am just trying to figure out what type of usefulness I can get out of them.

Would you have anything like a rep set a dispo or appt and the setting container sends out a txt message to the appt person cell phone for a reminder?

dreedy

; sending email address
email_from => vicidial@local.server

; subject of the email
email_subject => Scheduled callback alert for --A--agent_name--B--

email_body_begin =>
This is a reminder that you have a scheduled callback right now for the following lead:

Name: --A--first_name--B-- --A--last_name--B--
Phone: --A--phone_number--B--
Alt. phone: --A--alt_phone--B--
Email: --A--email--B--
CB Comments: --A--callback_comments--B--
Lead Comments: --A--comments--B--

Please don't respond to this, fool.

email_body_end

matt, i was curious what type of container would be used for the launcher? any examples you could share?

What exactly is "the launcher"?

vicidial/admin_launch_trigger.php

That script was designed as a generic framework we built for a customer for a set of custom client perl scripts 3 years ago so that the client could launch them on their own through a web page. There really is no function for them within the VICIdial codebase currently.

ah ok, gotcha. thank you sir

We use them primarily for new feature requests to avoid trying to create a "preference" when a new feature is added. This way the settings container allows visible feature configuration that's upgrade-proof. Instead of altering admin->servers or the campaign settings screen (or any other module), we put a settings container in place that will survive upgrade yet allow the client to specify said "preference".

We used to create a whole new table for this, but settings containers allow this without any custom tables. Handy.

Some clients insist on modifying the existing page (lists, campaigns, users, etc), but not all of them.

Bill

damn that sounds useful, you mind sharing an example?

Usage isn't complex enough to have an example. It's just a Key=>Value pair. The container ID is the Key, the Value is in the Entry, which could be a single item, multiple items, or even several more key=value pairs (although that's kinda dangerous as clients tend to screw that up, whereas ONE key->value pair per entry has proven safer over time).

We also generally put a ticket # or other identifier in the Container Notes field for reference in case someone says "um ... whazzis?"