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

Hierarchical Custom Fields - Input, Display and Search

    Details

    • Type: New Feature
    • Status: Done/Fixed
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: 3.3.alpha
    • Fix Version/s: 4.3.0
    • Component/s: Core CiviCRM
    • Labels:
      None

      Description

      Specifications TBD.

      Check Implementation details BELOW

      Check out these implementations for possible use:

      • I like the user experience on this one - need to think about how options / hierarchy is defined by admin. Might want to consider a simple input mechanism like we've used in premiums (a text box w/ list structure, or even a wysiwyg w/ nested list building support)

      http://wimleers.com/demo/hierarchical-select

      ==========================
      Example use case:
      custom field: what colour is your shirt?
      blue
      --dark blue
      ----navy
      ----prussian blue
      ----ultramarine
      --light blue
      ----cyan
      ----sky blue
      red
      --dark red
      ----burgundy
      etc.

      We have
      John: dark blue
      Jane: navy
      Jean: cyan
      Joan: blue
      (all the rest being some shade of red)

      a search for blue returns the four contacts that are marked respectively 'blue', 'dark blue', 'navy' and 'cyan'
      a search for dark blue returns the two contacts marked 'dark blue' and 'navy'
      a search for cyan returns only Jean.

      IMPLEMENTATION DETAILS:

      • We will implement this as a set of custom fields (CF) of type select. The interface will just present this as one custom field for view/edit. Add a new html type "Hierarchical Select". Add a new column called "parent_id". Level 1 will have a null parent_id, all the others will have a parent_id of the custom field at the previous level.
      • Each of the custom fields will be associated with an option group. You can either create or reuse a new option group. A new ajax interface will be implemented to "create new option group". This same interface will be used for the existing select / checkbox / radio custom fields.
      • We will support an n level hierarchy
      • Each level will have its own column in the custom value table (due to the step 1 plan)
      • A new table will be created to store the mapping of:

      Level 1 value -> set of values in Level 2
      Level 1 value, Level 2 value -> set of values in Level 3
      Level 1 value, Level 2 value ... Level N - 1 value -> set of values in Level N

      This table will need at least the following columns

      • CF id of the level 1 field
      • CF id of the level 'X' field
      • option value of the level X
      • option value(s) of the next 'level' separated by CRM_Core_DAO::VALUE_SEPARATOR
      • The configuration screen for this field will be "ajaxy". The admin will first specify the level and the option groups for each level (and create the option groups if needed)
      • The next step will be mapping each level to the next level. We can potentially integrate this with the first step and play with it as we build the interface

      Query:

      To get the list of elements to display for level Y, we need the

      • CF id of root element
      • CF id of level X element (predecessor of Y)
      • option value 'value' of X

      with the above info we can query the above table to get the list of values to display and then get the labels from the
      Example:

      Assume a 3 level structure:

      Level 1 is the numbers: 1, 2, 3, 4, 5 .. 10
      Level 2 is the alphabets: a, b, c, d ... z
      Level 3 is the greek letters: alpha, beta, gamma, delta ...zeta

      1 -> a, b, c
      2 -> c, d, e
      3 -> a, d, e

      a -> alpha, beta
      b -> beta, gamma
      c -> alpha, beta, zeta

      Restrictions:

      • This set of custom fields will not be exposed to a profile
      • For search and export this set of custom fields will be exposed individually

        Attachments

          Activity

            People

            • Assignee:
              deepak Deepak Srivastava
              Reporter:
              dgg David Greenberg
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Time Spent - 3 hours Remaining Estimate - 2 weeks, 2 days, 4 hours
                2w 2d 4h
                Logged:
                Time Spent - 3 hours Remaining Estimate - 2 weeks, 2 days, 4 hours
                3h