CRM-19888 On contact import, State field does not respect default country

    Details

    • Type: Bug
    • Status: Done/Fixed
    • Priority: Minor
    • Resolution: Fixed/Completed
    • Affects Version/s: 4.6.17, 4.7.15, 4.7.16, 4.7.23
    • Fix Version/s: 4.7.30
    • Component/s: Core CiviCRM, Import
    • Labels:
    • Versioning Impact:
      Patch (backwards-compatible bug fixes)
    • Documentation Required?:
      None
    • Funding Source:
      Contributed Code
    • Verified?:
      No

      Description

      When CiviCRM is configured with multiple countries enabled, the state field may be set incorrectly when contacts are imported. This occurs when

      • Multiple countries are set as "Available" on Administer-Settings-Localization
      • The state abbreviation is ambiguous among the enabled countries
      • The country field is not specified or is blank in the record(s) being imported.

      Thus, if "United States," "Guyana," and "Netherlands" are made available, and the state field contains the abbreviation "UT" a record with the country specified as "United States" will correctly be assigned the state "Utah." If no country is specified, the State/Province field will be set to "Upper Takutu-Upper Essequibo" in Guyana. If only one country is enabled, the State/Province field is correctly set.

      This behavior has been confirmed in the current CiviCRM public demo/sandbox (as of 17/Jan/16 17), which shows as version 4.7.16.

      If no country is specified, the configured default country should be used to identify the correct state abbreviation.

      To reproduce

      • Go to Administer-Localization-Languages, Currency, Locations
      • Set "Default Country" to "United States"
      • Add United States, Guyana and Netherlands to the Available Countries
      • Add United States, Guyana and Netherlands to the Available States and Provinces
      • Save the configuration
      • Import the attached file civicrm_import_bug_test.csv, mapping columns F-K to Street Address, Supplemental Address 1, City, State/Province, Postal Code and Country for the location "Home"
      • Map columns L-Q to Street Address, Supplemental Address 1, City, State/Province, Postal Code and Country for the location "Other"
      • Complete the import
      • Examine the imported contact record for John Doe
      • Address in Home location will show as being in Upper Takutu-Upper Essequibo, Guyana
      • Address in Other location will show as being in Utah, United States

      The workaround for this issue is to ensure that, when importing address data, that a valid country is always specified when there is data in a State/Province field.

        Attachments

          Activity

          [CRM-19888] On contact import, State field does not respect default country
          Eileen McNaughton added a comment -

          Dan O'Brien thank you for these really clear replication steps. I am struggling with a bug I'm replicating inconsistently & since it seems to intersect with this I have tried fixing this in the hope the other will be resolved. I have replicated this in a unittest using your instructions & submitted a PR. (not sure yet if it does answer my bug or not - that is the next step for me)

          Peter Davis added a comment -

          anything need doing to nudge this along?

          Eileen McNaughton added a comment -

          This fix

           

          https://github.com/civicrm/civicrm-core/pull/10740/files

           

          is deployed on wmf & working.

           

          Since I put the PR up you need to find another merger so look at it - so J should try to trade review with Coleman or Monish (prior to an incident earlier this year it would have been OK for J to review it & for me to merge it - hopefully once we've worked through the 'review review' we'll get back to that state again because I think having Jitendra review this is enough external review given the nature of this fix, and much more efficient than getting him to review something he has no skin in & getting someone else to review this).

          Peter Davis added a comment -

          Jitendra Purohit per eileen's comments above - not sure I follow why you can't QA it unless you hav been involved somehow already

          Eileen McNaughton added a comment -

          no the issue is that even if he QAs it I can't merge it based on his QA because I raised it (I'm hoping this is a temporary rule because it's probably doing the opposite of making us safer). So better to start by finding someone who can merge it & then figuring out what you need to do to get them to look at it. In practice this probably means Monish as he is more likely to be able to find the time.

          Eileen McNaughton added a comment -

          This has been tested & QAd but there is some phpcs failure that I can't find at the moment

          Eileen McNaughton added a comment -

          phpcs failure was unrelated - I just merged this

            People

            • Assignee:
              Jitendra Purohit
              Reporter:
              Dan O'Brien

              Dates

              • Created:
                Updated:
                Resolved: