Caller ID Superfecta

Just thinking out loud... Slide the debug box down to the bottom half of the screen opening up space to the right of each provider. In the PHP code and MySQL record for each provider, add support for custom1, custom2, custom3, custom4, and custom5 fields. In the PHP code, these would be used for 10-character labels. In the MySQL table, these fields would store the actual data entered by the user.

CID Superfecta form entry would be generated by creating data entry prompts for any non-blank custom field, e.g.

Service Name Enabled Disabled
Who Called: * * Username: __ Password: __ Threshold: __ SpamFlag: __

CID Superfecta PHP snippet for WhoCalled would include:
$custom1="Username";
$custom2="Password";
$custom3="Threshold";
$custom4="SpanFlag";
$custom5="";

MySQL table for WhoCalled would be expanded to include 5 new fields: custom1, custom2, custom3, custom4, and custom5

When Superfecta form was filled out, entries in custom1-5 would be populated in the MySQL table and would be looked up whenever a WhoCalled retrieval was requested.

I like it. The existing database schema is expanded for the extra fields, and then the rest of the existing logic holds up fine. Also, doesn't sound super ugly to deploy.

Jeremy often has really simple but elegant solutions for things like this - Ill be Watching this case to see his thoughts you can bet.

Ok,

I've been thinking about this one a bit, and I agree that we need to be able to easily add new sources that require some sort of customization like a login, or spam threshold, etc.

The MySQL table can be tweaked to hold all of this information (more on this in a minute), but the real question becomes how do we trigger that the information is needed? I think there are two approaches we can take here...let me have your thoughts.

1. Each source can have two files in the bin folder. We could name one source-Source_Name-exec.php and it would basically be the same scripts that exist there already, and the second file would be source-Source_Name-conf.php. This second file would hold configuration information in it. Things like the form elements needed for the source, a description of the source, and any further configuration we might put in place down the road.

1. The second idea is really to do basically the same thing, but include it all in one file. In order to do that though, we need each source script "be aware" if it is being used for retrieving CID or configuration purposes. We could probably do this simply be setting a $get_cid boolean variable to true in callerid.php and then checking for it in each source. As I write this out, I think I like this option better.

• source - This column would have the name of the source that was using this row. We would reserve "base" for basic module elements that are source independent. Things like the curl timeout, prefix url, etc.
• field - This would be the name of the field that was needed, things like "username", "password", etc.
• value - This would be a text field that will hold the value entered by the user.

Hope what I'm thinking transferred into print here, but if it didn't please ask so I can explain further.

Ok, I went ahead and implemented option 2 with a rework of the MySQL database.

I wrote appropriate code for the install scripts so that values will get pulled from the old database into the new format.

This needs to be tested further, particularly with sources that require some sort of authentication.

All - I had my primary workstation fail outright three days ago - and Im still picking up the pieces. I expect to be able to address this ticket in the next 48 hours. Looking forward to testing option 2. (That's the option I had mentally voted for - so great choice! LOL.

1. General user interface. When clicking on THE NAME of a data source, the screen jumps around in a very distracting manner.

NOTE: Please try and find a way to avoid the screen jumping about - it makes me seasick. :)

2. Superfecta cache works. successfully cached a Previous Sperfecta provided CID. Extremely fast.

3. VoipCNAM token passing from config works as expected. No problems found.

4. Trunk provider data source works as planned, no problems found.

WOW Jeremy - Nice work!

Awaiting documentation on creating new data sources for full test of this capability.

QA: Continuing. Results are positive so far. Testing various new capabilities and validating expected performance.

QA Accepted.