The Address API is not taking into account the country_id when figuring the state_province_id when given the state name or state abbreviation, even if country_id is provided...
Notice the state_province_id is 3497, which is Maryland, Liberia. It should be 1019.
This happens regardless of which countries are enabled in the Localization settings. It also does not respect the "default country" setting, if the country_id is not provided.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
GraphQL error: The resource that you are attempting to access does not exist or you don't have permission to perform this action
No child items are currently open.
Linked items
0
Link issues together to show that they're related.
Learn more.
We found that Montana is another state that is affected by this bug.
It turns out that the CRM_Core_BAO_Address::buildOptions() is not getting parameters passed through from _civicrm_api3_validate_integer() to _civicrm_api3_api_match_pseudoconstant() to limit the list of available states to the country_id parameter (or default country).
It also turns out that the available options for the state_province_id field are generated in the 'validate' step, and not recalculated again. Validation is not catching this condition.
Candidate PR for fix coming...
BUT, this may also be affecting Counties ... and my fix still feels a bit "one-off".
On my local, I can reproduce the problem by running:
<?php// FILE: /tmp/z.php$cid=civicrm_api3('Domain','getvalue',array('id'=>1,'return'=>'contact_id'));$r=civicrm_api('Address','create',array('version'=>3,'debug'=>1,'contact_id'=>$cid,'location_type_id'=>1,'street_address'=>'123 Some St','city'=>'Hereville','country_id'=>'US','state_province_id'=>'California','postal_code'=>'94100','options'=>array('match'=>array('contact_id','location_type_id'),),));print_r($r);
Hmmm, it's possible that passing in "US" vs 1228 for the country code causes it to break. It would be in the options lookup in _civicrm_api3_api_match_pseudoconstant() I would guess.
I wouldn't want to live with the API setting states to the wrong code, but this problem is really a symptom of something deeper/architectural in APIv3 ...
It would be easy to change your test to use 1228 for the country_id ...
I've never been a big fan of an api parameter accepting multiple types of data..."US" vs. 1228, pick one and stick with it .. but...I suppose we could add some more hacky sauce to lookup the numeric country_id if the $additional_params['country_id'] is not numeric in _civicrm_api3_api_match_pseudoconstant() ...
I'm open to suggestions for next steps here. The PR past the current test contract that github uses. But what totten discovered likely means that their are other API calls that will fail when the country_id is passed a value "US" or "United States" .. Somebody will likely scream a bit soon ...
Options?
If we add hacky sauce, it should probably be in _civicrm_api3_validate_integer() where our special case is handled, and if the country_id is not numeric, we try to figure out the numeric country_id .
Should this figuring out of country_id actually happen in some preprocessing before the params get to that function ... like standardize that the received params are "sanitized" and country_id is transformed to it's numeric id value in the beginning of the API action process...
What's different about the state_province_id is that it's not really an option group, it's an entity type, and that's how we get into this situation, because entity names are not unique, they have multiple properties i.e abbreviation, full name, id, etc.. not just name and label, and any of these properties can be passed into the API, and people can add/alter them too. Should the API handle these fk reference / option group hybrid thingys in a more robust / generalized way? Can anyone thing of another similar property that could conceivable have the same problem, thinking too that people could have their own custom entities with properties similar to state_province_id...Is APIv3 worth investing this kind of thought into?
thanks for jumping on this @jackrabbithanna - I'm fine with hacky-sauce if we can catch it in a unit test & protect against regressions @colemanw that would be an api v3 fix - not sure about apiv4 impact