Uploaded image for project: 'CiviCRM'
  1. CiviCRM
  2. CRM-804

Configurable Basic and Advanced Search Selectors (via Profile)


    • Type: New Feature
    • Status: Done/Fixed
    • Priority: Major
    • Resolution: Fixed/Completed
    • Affects Version/s: None
    • Fix Version/s: 1.5
    • Component/s: None
    • Labels:


      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.




            • Assignee:
              kurund Kurund Jalmi
              dgg David Greenberg
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created: