Author Topic: Systematic way to add to advanced search (was: Search based on preferred con...) (Read 1512 times)

Michael McAndrew · February 28, 2009, 12:09:27 pm

Hi Dave,

(from http://forum.civicrm.org/index.php/topic,6802.0.html) Understand your concerns about adding even more stuff to the advanced search, and thanks for the encouragement of my developer resources - I hope I'll be in a position to do this soon.

I realised that a kludge for this would be to add a custom field for contact preference which I could then make searchable. Obviously this isn't ideal because I've duplicated fields now but it did give me an idea for a longer term solution to "the EVEN MORE stuff on advanced search" problem.

I wonder if at some point we could move in a similar direction with the advanced search screen as we are moving with the contact edit and view screens - i.e. making core data behave more like custom data.

Given that core data is stored in much the same way as custom data - the main difference being that they are stored in civicrm_contact rather than civicrm_value_xxx - it strikes me that the infrastructure already exists to allow any of the core fields to be specified as searchable using the "is searchable" functionality that exists for custom data. Think of it as treating core fields as "reserved custom fields".

I presume what would be involved here is adding data definitions for core data to custom_field and custom_group and then adding a reserved fields for both tables.

Those fields that are already searchable via the advanced search interface could be handled by adding a 'reserved' value in the is_searchable column.

Whilst it would be some work to set up, it would be a neat way of dealing with lots of "Can you add x to advanced search requests" and could also incorperate future changes to core fields. It would also allow people to better customise advanced search - there is an argument that says, if we are turning off visibility the core field x in contact pages, we should also turn off ability to search on core field x in advanced search.

OK, well I realise that these are just ideas at the moment and I imagine you want like to increase your 'people with ideas' to 'people actually implementing ideas' ratio but ideas are better than nothing at least. Would be interested in some feedback and crit. to know if this has legs.

Michael

Dave Greenberg · February 28, 2009, 05:52:42 pm

First reaction is that this is a good reminder that whatever solution(s) we implement to allow more granular control over contact editing and viewing should potentially have "consequences" for the search interface (e.g. if you're excluding Date of Birth from contact edit and view, then you PROBABLY don't want it in the search screen).

As far as this specific approach, I would have some concerns about query construction - esp. for fields that are 1 : many relative to the contact record - but lobo and kurund and team would probably be better to speak to that. I also scratch my head about how to deal with layout control when every field is included dynamically in the form. Currently the core parts of advanced search have a relatively tight multi-column layout which would need to be rethought. Typically when a form is totally dynamic - the fields are just stacked:

Label : Field
Label : Field

... which is not necessarily an good user experience when there are lots of fields.

CiviCRM Community Forums (archive)

News:

Author Topic: Systematic way to add to advanced search (was: Search based on preferred con...) (Read 1512 times)

Michael McAndrew

Systematic way to add to advanced search (was: Search based on preferred con...)

Dave Greenberg

Re: Systematic way to add to advanced search (was: Search based on preferred con...)