Configurable Basic and Advanced Search Selectors (via Profile)

We need the ability to modify the data columns which are included in the built-in Basic and Advanced Search selector table (search results listings). We will use our existing Profile mechanism - with special UFGroup(s) "joined" to the "Search" component - to support alternate user-defined sets of selector columns.

We will pass a particular "Search Profile" into the Basic Search and Advanced Search forms by passing the uf_group.id as a Post or Get parameter (id=uf_group.id). If this value is NOT set, the code should default to use the current defaultReturnProperties (and hence display the current 'hard-coded' selector columns).

Profile Groups (uf_group rows) will be "tagged" as Search selector configurations using uf_join - i.e. we can select uf_group rows where uf_join.module = "Search" and is_active = TRUE.

1. Creating a "Search Profile"
1.1 Add a checkbox to UF/Form/Group - uf_group_type set labeled "Search View"

1.2 If this value is checked, insert (or verify existence of) a uf_join record for this profile with module="Search" (and make sure "un-check" case is also handled as with other options).

1.3 User can now add Profile Fields (uf_field records) to this Profile as usual. The significant uf_field values for this case are:

• field_name + location_type_id + phone_type : These will control the columns included in the search selector
• is_selector AND is_active : Both must also be true for this field to be included as a selector column
• weight : Controls order of selector columns
• label : If provided, over-rides field name used in selector column header

2. Search
Basic and Advanced Search will continue to present the default hard-coded selector table headers/columns UNLESS a Profile ID parameter is passed.

For Advanced Search, we will give the user a drop-down to select from existing "Search Views" (if any). For Basic Search, the default (hard-coded) selector can be "over-ridden" by passing a Search Profile id as a GET parameter (id=N).

2.1 Advanced Search Form: If there are one or more uf_join rows in the domain with module="Search", then include a new <select> field - "Search View". This drop-down can be placed to the right of the sort_name field. The null option label is "default view". Other options are the id and title of any uf_group which is "joined" to "Search".

2.2 If non-null search profile is submitted, then the $returnProperties for the search results selector need to be generated from the uf_group's uf_fields.

Per Lobo - you should be able to use the following function to construct the $returnProperties to be passed to Query.php from the Profile's fields:
$returnProperties =& CRM_Contact_BAO_Contact::makeHierReturnProperties( $fields )

2.3 Basic search should also be able to use profile-based Search Views - if an id=N value is passed into the Basic Search form session values via GET (URL) param.

NOTE: Much of this functionality is handled by the current Profile Search/Listings code. We should avoid duplicating existing functions - and may need to refactor/move some code from UF into Core. Check w/ Lobo after reviewing this spec if you have questions about implementation.