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

Option to Allow multiple Clients for a single Case

    Details

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

      Description

      Background
      ==========
      Front Line (Human Rights Defenders) uses CiviCase for their work and they often need to associate multiple contact records with a single Case. However, for other CiviCase users (e.g. Physicians Health Program) - this functionality is not needed and would violate their privacy policies.

      This is a sponsored deliverable for Front Line/HRD. Estimate for this functionality is 20hrs. Please track and report time on this issue.

      Imlementation
      ============
      1. Enabling multi-client case support:
      Add an element to the CiviCase settings file : CRM/Case/xml/configuration/Settings.xml, something like this (feel free to modify structure if there's an easier approach). Default (if this setting is not present) is FALSE.

      <Settings>
      ...
      <AllowMultipleCaseClients>1<AllowMultipleCaseClients/>
      ...
      </Settings>

      All behaviors described below are available only if this setting is TRUE (1).

      2. New Case
      2.1 New Case form:
      When creating a new case, user needs to be able to select one OR MORE contacts as the client. When multiClient is enabled, use the token-input-list-facebook style input widget for 'Select Contact' field instead of the usual ac_input widget.

      If the user is using 'create new contact' method on this form, when they've filed in the pop-up Profile dialog, add the newly create contact 'token' to the token-input-list-facebook input widget. (So user can potentially create 2 or more contacts AND associate them with the new case from the new case form.)

      2.2. Post process:

      • modify code to support inserting multiple civicrm_case_contact records
      • modify 'automated activity insert' method to handle insert of case activity records with multiple target contacts (each case 'client' is a case activity target contact_id, so an activity_target row is inserted for each).

      3. Manage Case
      3.1 Case Roles pane should display a row for each 'client' (i.e. each case_contact record for the current case).

      3.2 Client 'display' cell in Case Summary table (top section of Manage Case page) needs ability to display multiple clients.

      • if >1 client linked to this case, add a link below the currently viewed contact display name : 'and $count more...' where $count is the number of other clients (e.g. case contacts for this case minus 1).
      • Clicking on this link loads a jQuery dialog (overlay box) containing a list of the other contacts linked to this case. Contact names should be links to contact summary for that contact (to make it easy to navigate between multiple clients for the case).

      3.3 'add client' link included below the contact names in this cell. I think the easiest UI for this is to a use a jQuery dialog pop-up similar to the 'Add new role' dialog in the Case Roles pane. The 'relationship' dropdown is omitted and dialog title is 'Add Client to this Case'. User has the ac_input widget to find and select contact to be added as a client.

      NOTE: This UI approach supports adding additional clients 'one at a time' - which I think is fine given that it's a quick dialog.

      NOTE: Ideally we can update the Case Roles listing to show the new client AND the Case Summary client 'cell' to show the new client name w/o reloading the entire page. Phys Health has a long-standing request to avoid page reload when adding new case roles in general, so this would be good to do as part of these changes.

      4. Case Activities
      4.1 New / Edit (case) Activity form
      Read-only 'Client' field should list 'all' case clients. Multiple client display names s/b separate with semi-colons. Post process code (create) needs to insert activity target records for each client.

      4.2 View (case) Activity
      jQuery dialog pop-up should list 'all' case clients (i.e. all target contacts) in the Client row. Multiple client display names s/b separate with semi-colons.

      5. Case and Activity Selectors
      5.1 Contact Case Tab
      Cases should appear in any contact's case tab where that contact is a client (i.e. there is a case_contact record for that contact id). I don't this this will require any code changes - just noting to confirm expected behavior.

      5.2 Case selector
      Client column in case rows needs to be able to list multiple clients.

      • if >1 client linked to this case, add a link below the currently viewed contact display name : 'and $count more...' where $count is the number of other clients (e.g. case contacts for this case minus 1).
      • Clicking on this link loads a jQuery dialog (overlay box) containing a list of the other contacts linked to this case. Contact names should be links to contact summary for that contact (to make it easy to navigate between multiple clients for the case).

      5.3 Case Activity selectors
      I don't think changes are needed for the drilldown or jQuery grid activity selectors (since we don't list the client in these selectors).

      6. Find Cases
      6.1 Should return case when any 'associated' client name or email is entered. Should not return multiple rows for the same case. This may require adding DISTINCT to the search query.

      NOTE: Check Advanced Search results on Case criteria as well to make sure we don't return duplicate contact rows if > 1 contact is linked to a case that fits the search criteria.

        Attachments

        1. Picture 14.png
          90 kB
          David Greenberg
        2. Picture 15.png
          85 kB
          David Greenberg

          Issue Links

            Activity

              People

              • Assignee:
                mover Michał Mach
                Reporter:
                dgg David Greenberg
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

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