Filter from custom_ tables

[nrc]

So I use this code currently in the FILTER

( phone_number not in (select phone_number from asterisk.vicidial_dnc) ) AND called_count <=8 AND lead_id IN (select lead_id from custom_92706788 where HPC >= 100)

BUT I have to hard code the custom_LISTID part, and while I (administrator) can do this, I don't want this burden on the supervisors. So does someone know a way for the FILTER to pull directly from a custom_ table without hard coding the LISTID into the query string?

Thanks

[mflorell]

Custom fields cannot be included in filters in vicidial.

[nrc]

Well my filter works, just wondered if anyone had a JOIN or some other way to "make" it work other than hard coding.

If not, can you include this function somehow Matt?

[mflorell]

There are a lot of other issues involved here, consider for example a campaign with 400+ active lists. The filter using custom fields on a campaign like that would generate hundreds of table joins and create SQL that was extremely long, resulting in an SQL query that would take so long to run that it would cripple the system.

There is also the matter of leads being moved from their original custom fields list ID to another. Making custom fields usable in filters for everyone would be a very difficult feature to make work in all cases.

[nrc]

Wouldn't that same issue of having 400+ lists happen with any report that uses the custom data tables?

I've sent in a quote request, we never have more than 1 active list at a time per campaign, so i don't think this will apply to us.

Let me know what it will cost.

[mflorell]

A report runs once, and the way we run it there is no lock on the vicidial_list table.

The Hopper runs hundreds of times a day, and it does lock the vicidial_list table because it has to.

Those are two very different things, and with a lot of lists, using a SQL filter on custom fields could easily make the system unusable.

We have to develop Vicidial for everyone that uses it, not just one company's use case, and adding this complex feature will result in more issues for more clients. We have added features like this that are disabled by default before, but I'm not sure how we would do that in this case. It's something that I would have to spend more time looking into.