Can we add postal code to Autocomplete Contact Search fields?

[joanne]

Australia has only 8 states/territories that could be in a postal address but about 1000 4-digit postcodes.  To find the one Jane Smith I want amongst the 20 or more in the database it would be much better if I could include postal code in the quick search results rather than the state (or city - as they are not unique).  I would imagine that could be true for others as well. 

Seeing postal code is in the civicrm_address table and that must already be included in the code for displaying the search results, I thought this might be something I could do even with my limited coding abilities.

What do people think?

[Erik Hommel]

I would guess it is pretty straight forward, but I have spent many hours in the past with things I thought were pretty straightforward 

[JonGold]

I added phone extension to those results, the git commit is here, if you want to go poking around the code:
https://github.com/PalanteJon/civicrm-core/commit/aebdef3c4f78a2ebf31404f04cc6c08464f11d77

This may be different in 4.5 - I know Coleman has done a bunch of work on this stuff - but in current versions of Civi, autocomplete searches use the "getquick" API function, which returns a limited subset of fields.

[joanne]

Well, it turns out that I could sort it out myself - because there wasn't actually any coding required.

I just had to add postal_code to the Autocomplete Contact Search Option Group!

Now I did sort of know that Option Groups existed, but I spent 2 hours trawling through the code before I reached the conclusion that there was nothing at that level that specifically excluded postal_code from the autocomplete search  lists or specifically include the street_address etc, so it must be set at the UI level somehow and then I finally remembered option groups.

I have spent a far amount of time with our 'formal' documentation ( book and documentation wiki) over the last couple of months and I don't recall seeing anything on option groups and still can't find anything substantial on them.

Many option groups are associated with custom data or customisable lists but is there a big hole in the documentation for some of the option groups or are my observation/searching skills just not up to scratch?

[joanne]

I spent last night when I should have been sleeping going hot with embarrassment and cold with fear as I thought about my previous post. Embarrassment at the foolishness of it and fear at the scorn being silently heaped on me as people thought "Exactly how does she think the option group is configured if not via code?"

Up until now my efforts to understand what is going on have been restricted to the CRM and templates folders and that is what I was referring to when I said "2 hours trawling through the code" and "nothing at the level".  Until now I have left the sql folder alone - although I am not sure why as it contains files that I actually understand.
 

[Dave Greenberg]

Hi Joanne - might be best for you and I to just chat on Skype or IRC so we can figure out together what the doc holes are / what would be useful for folks (including potentially where to warn folks to be cautious about altering option group items that are used programmatically).

Separately, did adding postal_code to that option group allow you to search by postal code in the Autocomplete Search? If so, let's discuss including that as an option going forward.

[joanne]

Adding postal_code to option group Autocomplete Contact Search lets you choose to see postal-code in the results returned during an auto-complete contact search.
Adding postal_code to option group Contact Reference Autocomplete Options lets you choose to see postal-code in the results returned during an auto-complete contact reference search.

I think it would be worthwhile having these included a standard options (by adding an option 8 to option_group_id_acsOpt  and option_group_id_acConRef  in  /civicrm/sql/civicrm_data.mysql for new installs?  more complicated for existing upgrades?)