We have had a few requests from folks to extend the search code with their own SQL queries while taking advantage of the tasks available with search (print, mailing labels, export, smart groups, adding to group etc). This has been on our list of things to do, but we had not made any progress. Some example where this would be useful are:
- Give me the set of all household's who have a household member residing in district X. More details here. The search form can be set to just include a text box for the household name and a multi-select element for the district to restrict the search criteria
- Give me the set of contact(s) who have donated more than an input amount in this date range.
- Various combinations of AND/OR/NOT which civicrm search does not handle.
The original goal was to splice in pieces of user sql with the query generated automatically from form values. I prototyped this version a few weeks back on trunk and made some progress. However it seemed to be a bit restrictive to be useful (IMO). This approach had quite a few drawbacks:
- Cannot integrate with tables not part of the current search
- Form elements are restricted to current search form elements
- The where clause is influenced by the current query builder
- Cannot have conditional sql based on input values
I decided to change the approach significantly and write an interface that abstracts the way the core search code integrates with the rest of the task code base. While there is an implicit interface, making it explicit and well defined allows us to plug-in different "search forms" and write custom specific search code. You can check a first version of the interface
here. A simple search form that only searches household's is
here. Note that this is still in development and hence will change over the next few days/weeks. The code is structured fairly nicely and took me a few hours to integrate the above changes intro trunk.
The main disadvantage of this approach is that users will need to write form building php code and a smarty template (tpl) file to create a custom search extension. We will make this easier by providing a few samples and migrating our current searches (basic, builder, advanced) to follow this structure. However, this approach gives the user much more control over the form and database. I have not yet figured out how to integrate permissioning into this system.
Comments
I'm deeply interested in further development concerning the advanced searches. CiviCRM is really great but the major shortcoming we face is the lack of really advanced searches (especially the AND/OR possibility) along with the fact that we can't build labels (or export contacts) of individuals with theor Ooganisation name. I guess such a custom search would address both issues at the same time. The link does not seem to work for now. Is it possible to check it in order I can have a closer glance? CiviCRM really rocks!
sorry, i restructured the code a bit and broke the links. the links are now fixed
lobo
Solr, with its faceting and full-text indexing capabilities, would be a very powerful replacement.
i did a mockup on this a few months ago, and wrote a few thoughts at: http://civicrm.org/node/104
i suspect i'll move this into production in 2.1
lobo