Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Trivial
-
Resolution: Won't Fix
-
Affects Version/s: 3.0
-
Fix Version/s: Unscheduled
-
Component/s: CiviContribute
-
Labels:
-
Versioning Impact:Patch (backwards-compatible bug fixes)
-
Documentation Required?:None
-
Funding Source:Needs Funding
Description
Addresses rendered into the Confirm and Thank You pages of CiviContribute render the billing country as the ISO3166 two letter code, and not as the human-readable name of the country. This is not the practice of either post offices or people in most countries.
For example, here's an example from just released 3.0:
My Left Toh
40 Free Wi Fi Street
Ho Chi Minh Q.1, 65
VN
The billing address was entered as "Vietnam", but it renders as "VN" in both the Confirm and Thank You pages.
The problem here turns out to be how the country_id is processed in CRM_Contribute_Form_Contribution_Confirm::preProcess(). The enclosed patch resolves the issue.
This has been tested against the Authorize.net payment processor.
Attachments
Activity
This problem also occurs in the CiviContribute Thank You email. The patch fixes this as well.
thanx for the patch
punting this issue to a later version since we also send the country value to the Payment Processor and we'll need to check if the PP's are affected
I've looked this for Authorize.net, and in that case, the parameter in question always should have been the human-readable name of the country. Of course, that may not have been the case for other processors.
A problem with the old implementation is that that you use a single parameter for what is potentially two separate purposes. in addition, you are assigning the parameter country a different value than what you typically do in CiviCRM; 'country' maps to civicrm_country.name, and not to civicrm_country.iso_code as it is in this unusual case.
Still, a good work-around would be to create a new parameter 'country_name' in analogy with what you do in address processing code, which is what you're doing here. We continue to assign the iso_code to 'country', but we also add 'country_name' to the parameter stream passed to PP code. This would allow us to change individual PP implementations to use the human-readable name as appropriate, but would leave any other PP implementation untouched.
Since 3.2 is a long way off, this is a way of getting this fixed sooner. I'm willing to supply a patch along these lines if it will get into 3.0.1 or 3.0.2.
I think the earliest we can look at this is for 3.1. This a pretty big change to make for 3.0. Also 3.1 is due to go code freeze in 3+ weeks. There are quite a few contributed processors, so testing a change like this will need to be across at least a majority of them
Note that my proposed work-around would not affect PP code – we simply define another key to get assigned to the template, and the old key's behavior is unchanged (i.e., the UI used a new 'country_name' key, and the 'country' key continues to be assigned to the ISO3166 code.
This would be entirely benign. You cool with that?
We are more open to adding this in 3.1
we've been burnt pretty badly with completely benign changes in the past, and that part of the code is quite central
Rob Thorne looks like this patch never made it in... want to send a PR for it?
I'm closing this out based on the age of the ticket & the length of time it has not been worked on. I think lots of parts have moved since then
Patch is against today's trunk.