Caller ID Superfecta

The more I think about expanding the Spam Filtering aspects of Superfecta, the more I think we need to plan for some separation of the SPAM vs. caller ID functions in the user interface - possibly in the code as well.

Why? If fleshed out properly, the SPAM functions Configuration options could begin to become confusing when mingled with the Caller ID configurations. And they really are different functions.

It seems the codebase for doing SPAM like things is present in Superfecta to some degree already - so spinning this off to a new module seems like overkill. But again, separating the development of the two functions a little could help limit delays in one side of the project from effecting the other - and make the project scope a little more bite sized for new developers to get involved.

Perhaps if we make SPAM a subproject of Superfecta. This tactic would give the SPAM side of the project its own tracker time line and schedule.

This is meant as a strategic discussion - please chime in with your thoughts.

I think we can "separate" the SPAM and Caller ID functions by adding an additional SPAM Boolean value to the code. This would allow all scripts to set the value to true, and trigger some prefixed spam code onto the caller ID. We could even allow the user to decide what the code would look like through the UI.

Some of these scripts will both look up caller ID and return SPAM data, so I don't think we can effectively separate them out. But I do agree that they should be treated separately.

This was fairly easy to implement, and we only have one source of SPAM info at the moment so I went ahead and did it.

A new field was added to the MySQL database - spamtext varchar(20) default NULL

Jeremy - please add information about using this to your technical docs in the doc section at your next opportunity.

Database change portion of this project has been completed. A new case will be opened to discuss user interface changes for the SPAM sources.