Add Boolean logic to Advanced Search
It would be nice to be able to search the member database (or any database really) by specifying criteria such as:
Renewal_Due on or after Sept. 16,2008
(MembershipLevel = Gold OR MembershipLevel = Silver)
Right now, I think, I can only choose to AND (i.e., Match ALL) all the criteria or OR (i.e., Match ANY) all the criteria -- no mixing AND's and OR's. This is okay for very simple reports with only two criteria, but often not what is needed for reports with more than 2 filter criteria.
Old design proposal, not working on it yet and can be changed if we start working on it – https://drive.google.com/file/d/0B0f9kMyQqlBsZ3FQOWRiMERRNkk/view?usp=sharing
There are countless times where I wish we could do this. One example is I'd like to do "admin AND [active OR pending]"...
Marc Caruso commented
Why is there no ability to nest conditions in searches? This should be very simple for you to implement and would be very powerful. The current functionality requires multiple searches that force you to merge result sets. It's a pain in the butt.
Please consider allowing a mixture of AND and OR criteria in the advanced contact member searches. It would be nice if I could run something like:
(is MemberLevel1 OR MemberLevel2) AND (is Active)
Hayley Raymond commented
It would be very helpful if we could search using specific date ranges in the advanced search function. For example, it would be great if I could search for 'Renewal date last changed between April 1, 2019 and April 15, 2019' rather than just 'Renewal date last changed on or before/after, etc.'.
I am a new customer. I need this functionality.
Steven Reames commented
This is a fundamental search capability for most databases and clearly a high priority for users who've expressed their wishes. Why isn't this a priority for Wild Apricot?
Jillian Dubois commented
In advanced search, make it so some criteria can be "any" and some can be "all", within the same search.
Laura Stigler commented
In Advanced Search, when putting in more than one criterion, there should be the words "and" and "or" between each that could be checked. For instance, let's say my two criteria are 1) "Initial Contact"... is... "Museum" 2) "Notes" ...contain..."Museum". My desire would be to get a list of all non IWOC members who attended our talk at the Museum, but also there were few current IWOC members who attended that same talk. So I'd like one list that included all those people who were at the talk. Couldn't get it. But if an "and" were between those two criteria, that complete list would have been compiled. Hope I made myself clear!
Michael James commented
How about a real boolean search with a field sector that inserts the correct field name in the search. The IT people for the org will create these complex ones and then publish just a saved search, or a a report to the people that need to use it.
("Membership Level" -eq "Monthly" -or "Membership Level" -eq "Annual") -and "Member Status" -eq "Active")
Jon Carlson commented
Contact and member searches (particularly saved searches) need to be able to apply the "ANY"/"ALL" (i.e. "OR"/"AND") logic in a mixed way. For example, I might need to search for (Member Level of X OR Y) AND (Member Status is ACTIVE). That's just one simple example. Give me a way to group them and then connect the groups.
Possible way to present the concept - chain the searches. So build one search with ANY logic, then build another search with ANY logic, then chain the two with AND logic. Something along those lines.
Lynn Baumeister-Admin commented
There are several suggestions for vastly improving Advanced Search. E.g., checkboxes instead of radio buttons to allow for logic such as
(renewal preference = Paper AND (membership level = GOLD OR membership level = SILVER)
Why hasn't it been implemented yet
David Turner commented
We should be able to create email lists which include 'and' and 'Or' (not just 'is' or 'is not'. E.g. Members who are in city x AND have the title Dr.
Daniel Frankel commented
Please enhance the advanced search capability to include compound queries (re (x and (y or z)). Also, add more of the SQL to the query language.
Nancy Scanlan commented
I agree, let us combined Saved Searches. Would allow us to do a Boolean search divided into smaller steps. Could be easier for staff who are not clear on how to set up a single complicated Boolean search
John Barrett commented
I like Michael's idea of combining Saved Searches. It is a simple and easy to understand approach to enhancing the search capabilities. Another benefit is that it also allows you to leverage existing saved searches to build new ones rather than building new ones from scratch. It also lets you make changes to many saves searches by modifying only one. The one downside I foresee with this approach would be that someone changes one Saved Search not realizing that they will be changing the results of another. However, I still like this approach.
Michael Armata commented
Alternatively, you could provide a way to create a Search based upon a combination of existing saved Searches.
Andrew Steele commented
There's a new topic that's similar to this one. It suggests that dropdowns should also allow multiple selected in search, which makes a lot of sense. E.g. If you have a dropdown for states, and you want to find members in set of specific states, you currently have to add a new criteria for every single state. https://forums.wildapricot.com/forums/308932-wishlist/suggestions/15719559-filter-for-multiple-items-within-a-single-advanced
Walt Bilofsky commented
Advanced Search already works this way for multiple choice fields. Might that make it a fast implementation for radio button fields?
Although - what would that do to our existing saved searches? Would WA have to convert them all? Could it be done automatically?
Andrew Steele commented
I concur that a partial solution would be to make searches on radio button fields allow multiple selected. Combo AND/OR searches could be added later if that's more complicated to implement.
Tim Nott commented
A UX tweak to the proposal I would suggest would be to collapse nested groups when they are not being edited so that the entire query can more easily be read at a high level. The indentation is a good indicator, but when everything is in an editable state, it is more difficult to read.